2024-09-22 re-frame | Clojure Slack Archive

re-frame

Steffen 2024-09-22T09:34:18.849019Z

Hello All, I'm struggling with a simple thing: Getting the Authorization Header from a Response. I see it in the browser console, however I don't know how to get it in my app. I'm not that long in clojure(script) (I love it), so I guess I'm missing something obvious. I tried with https://github.com/day8/re-frame-http-fx using:

{:http-xhrio {:method :post
                   :uri (str "" username)
                   :headers         {"X-GraphDB-Password" password}
                   :on-success      [:login-success]
                   :on-failure      [:login-failure]
                   :format          (ajax/json-request-format)
                   :response-format (ajax/json-response-format {:keywords? true})}}

but i dont get any headers object at all in my response and I tried @superstructor https://github.com/superstructor/re-frame-fetch-fx

{:fetch {:method          :post
            :url            (str "" username)
            :headers         {"X-GraphDB-Password" password}
            :response-content-types {#"application/.*json" :json}
            :credentials :include
            :mode :cors
            :on-success      [:login-success]
            :on-failure      [:login-failure]}}

where i get some headers but not the authorization header (though I see it in the browser network tab).

{
    "ok?": true,
    "redirected?": false,
    "final-uri?": null,
    "status-text": "",
    "type": "cors",
    "headers": {
        "cache-control": "no-store",
        "content-type": "application/json;charset=UTF-8"
    },
    "status": 200,
    "reader": "json",
    "url": "",
    "body": {
        "username": "admin",
        "password": "[CREDENTIALS]",
        "authorities": [
            "ROLE_USER",
            "ROLE_ADMIN",
            "ROLE_MONITORING",
            "ROLE_REPO_MANAGER",
            "ROLE_CLUSTER"
        ],
        "appSettings": {
            "DEFAULT_INFERENCE": true,
            "DEFAULT_VIS_GRAPH_SCHEMA": true,
            "DEFAULT_SAMEAS": true,
            "IGNORE_SHARED_QUERIES": false,
            "EXECUTE_COUNT": true
        },
        "external": false
    }
}

could you please point me in the right direction?

p-himik 2024-09-22T09:57:53.266919Z

By "Authorization Header", do you mean literally the Authorization header? Or something else, like a cookie?

Steffen 2024-09-22T09:59:29.911429Z

I'm looking for this: Authorization: GDB eyJ1c2VybmFtZSI6ImFkbWluIiwiYXV0aGVudGljYXRlZEF0IjoxNzI2OTk4...

Steffen 2024-09-22T10:00:02.987709Z

But I'm also new on the whole auth topic. So if I'm going into the wrong direction, feel free to point it out

Steffen 2024-09-22T10:01:50.013889Z

I wanted to store the token in my app db to use it in further requests. I thought this would at least be more sensible than storing the password and use Basic Authentication

p-himik 2024-09-22T10:05:35.013189Z

I hope that's not a sensitive string, because you should not share such info on public servers. :) The Authorization header is a request header. Unless someone did it deliberately for some reason, servers don't respond with Authorization. I'm surprised you see it in a response. Assuming you're able to fetch that header - what are you going to do with it?

Steffen 2024-09-22T10:07:51.658679Z

no, it's just something local for testing 🙂

Steffen 2024-09-22T10:08:57.904389Z

I need it to authenticate requests. I want to store the token in my db (of the re-frame application) and use it for further requests. The documentation of the db I'm using (and want to authenticate against) suggests it this way: https://graphdb.ontotext.com/documentation/10.7/access-control.html#gdb-authentication

Steffen 2024-09-22T10:12:35.208749Z

Or am I totally on the wrong path here? 😄

p-himik 2024-09-22T10:22:25.441269Z

Yikes... GraphDB is very wrong from the security perspective. They have notes about the necessity of "encryption in transit", and that's totally true, albeit I'd call it just "HTTPS" and not a vague "encryption in transit" which can mean different things. But they don't seem to realize that storing anything secure in JavaScript is a recipe for stolen identity. Even if you use stuff like closures. Maybe they were thinking about communicating in a server-to-server manner, not from browsers. And since you're using a CORS request, you cannot even access the Authorization header, in principle - your browser prevents it. Replies for CORS requests are filtered and the client JS can access only a handful of headers. What they should've also provided is plain old cookies. It's a reliable and secure mechanism when you follow the guidelines. Nobody can intercept or steal anything unless there's a vulnerability in browsers or SSL. In any case, if the GDB server is configured to allow non-CORS requests then you can send such requests and responses should have that header. If the server is not configured to allow such requests, then it basically doesn't have what the docs call "GDB authentication" when it comes to browsers.

Steffen 2024-09-22T10:30:23.826519Z

thanks for this detailed answer. I guess I have to change my approach here then. I was using cors because for testing I have both running on my local machine and I was not getting my requests through. So today I learnt and will have to learn a lot more. Thanks!

👍 1

p-himik 2024-09-22T10:32:32.261709Z

If you have your own server, what I would do is proxy the GDB by that server and use good old secure HttpOnly cookies between browser clients and your server.

Steffen 2024-09-22T10:33:37.078039Z

Thanks for the advice. I will look into that!

Clojurians Log v2

re-frame