I have a web app that accepts both anonymous and authenticated request. If I post form data (with a file upload) anonymously to the web app, and then receive a 401 challenge, will I then resend all that form data again on the second request?
I am not trying to avoid 401 responses, but rather trying to avoid sending the request payload twice when receiving a 401 response.
I didn't receive an answer to this quickly so I decided to just watch the http traffic myself using Fiddler. The short answer is yes, the data will be sent to the server twice. Once for the original request, and again for the second request containing credentials.
It seems to me the best way to avoid sending form data to the server twice is to send a preamble request first that will handle any authentication, and then make your request that contains your form data.
Related
I'd read the article about WWW-Authenticate in RFC-2616.
I need to implement digest authorization of a web server on the embedded Linux environment.
I wonder if there's any way to aquire these information without a 401 response triggered.
Can't it with a trusted client just send request contains Authorization header by default?
Senario below is how I think a communication that RFC trying to explain.
Client request some document which need authorized(lack of proper header).
Client receive status 401 and the WWW-Authenticate header about further action need to perform, in order to access such document.
Client formed an Authorization header and send request again.
I wish to implement an Auth handler for requests that handles authentication with an OAuth Authorization server to allow the following:
import requests
requests.get(url, auth=KeycloakAuth())
What I've done so far is to apply a response hook when KeycloakAuth is called, so that when the client redirects the caller to Keycloak, the hook will see the Keycloak login page, post the credentials to Keycloak and get redirected back to the client.
However, this does not work for a POST, as requests makes a POST to Keycloak's login page instead of a GET due to the redirect. Keycloak doesn't return the login form in response to a POST and this fails.
I considered checking for the redirect in the response hook so that I can modify the redirect to do a GET to Keycloak instead, but it seems like requests' implementation of redirects bypasses all the hooks.
After poking into this a bit more, I believe this may be the wrong question to ask.
I was seeking a solution where, regardless of the original HTTP method used on the client (GET, POST, HEAD, etc), the library would automatically login to Keycloak, and then "replay" the original request to the client and make it effectively transparent to the user of the library.
However, this can't possibly work with OAuth 2.0 without further state management on either the part of the library or the client, due to the redirecting.
Suppose the original request was a POST, with some data. After finding that the user is not logged in, the User-Agent will be redirected to the Authorization Server for authentication.
This means that the original request's POST data will be lost, removing the opportunity for any replay, upon the User-Agent being redirected back to the client after authentication.
With some state management, the POST data could be stored for replay - it doesn't make sense to store the data on the server side since the data could be arbitrarily large, which leaves us with the user of the library to do the state management.
However, that amount of state management should probably not belong in a library, since the library will have to handle lots of cases to guarantee only-once delivery of the request, for example, which would be expected by the user of the requests library.
As such, this Auth handler is probably not something we can implement in a library.
I authenticate in Postman by sending a POST request to an api endpoint (https) with my credentials included. The response sets two cookies.
Set-Cookie →atlassian.xsrf.token=AGH6-ZEXS-8CED-D3BW|96bac852b72xxx42042593f13axxxxe7f3ff1d5f|lout;path=/;Secure
Set-Cookie →JSESSIONID=8C53xxx0xxxx46B4A5201A68C098604DF08;path=/;Secure;HttpOnly
I click the 'Cookies' button in Postman and see that these two cookies are saved. When I now send a GET request to a secured page, I get authenticated and receive the expected response.
However, I need to do this programatically, so I try to set the cookies manually by adding a header to the request, using the same values I got in the original response.
Cookie: atlassian.xsrf.token=AGH6-ZEXS-8CED-D3BW|5xxxxxxxxba42582fb230ac7d7416e81204|lout;JSESSIONID=7AFxxxxxxxx27A461A01C193C57D
I also delete the cookies saved in Postman.
Now, my request gets redirected to a login-screen, as I apparently did not get authenticated.
What is the difference between my first and second GET request? How can I make sure the request is authenticated correctly?
Sorry for the late reply.
In your first GET, postman will send the JSESSIONID to your server. You're already authenticated so the request will be obviously accepted.
But for the second one, you don't provide the JSESSIONID cookie and more important your JSESSIONID is not associated to a living Http Session.
For rest security I want to send an application key and a hash with every request. Actually I would like to have it as url parameter like
DELETE api.project.com/model/1?client=12345?hash=abcdef
Do you see any problem with this? Is there another way to send this data?
You should use Authorization HTTP header in request. If you send it as a query parameter it can be cached in many places i.e. user's browser, http caching proxy which may lead to leak of user's credentials.
On SO: Custom HTTP Authorization Header
I would like to send some sort of token on one request and store it at the client but not have that token retransmitted on subsequent requests.
Putting the token on the web page would "store" it on the client. If you don't want it retransmitted, this seems ideal, since it will only be stored until the browser page cache is cleared.
Maybe you should explain why you want to do this.
If you are sending the data to user in cookie then data will be retransmitted of every subsequent request..
There is no a way to send data to user in cookie but not have the data retransmitted with every subsequent request........
Might your goal be achieved with a session? You send the user a small token (a session ID) and subsequent page loads send only that session ID back to the server. You can then use the session to store (potentially much larger amounts of) data server-side.
Ways for the HTTP client to not return the cookie to the HTTP server:
The HTTP client could have support for cookies disabled.
The HTTP client could delete the cookie.
You can do it by manipulating the paths of the cookie and processing URLs - if you set your cookie with a path '/some/obscure/dir' then the cookie will only be included in requests to URLs starting with /some/obscure/dir