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.
Related
The image below depicts basic HTTP authentication. The client requests /family resource and it is asked to identify itself. It does and now it can access the /family. The client then also asks for /family/photos/kids resource which is in the family realm.
The client already identified itself for /family resource, but not also for /family/photos/kids. They are in the same realm, but the server doesn't know that the same client issued a request. Or does it? How does the server know that this particular client is also allowed to access /family/photos/kids on subsequent request? Is the password and username send on every request after the user has authenticated? Is the client asked for via pop-up for every request he/she makes? Are cookies set upon first authentication?
Basic authentication requires a header sent by client. No cookies or server session
When the client requests a resource, sends the Authorization header
GET /family
Authorization: Basic token
Where token is base64(username: password). Username followed by ':' and password encoded in base 64
If you are requesting a protected resourced from your browser for example a GET request, and you do not provide the header, the browser shows the autenticathion form and remember it for subsequent requests in the same domain
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.
I am trying to implement SSO with a vendor, and they require I send a HTTP request. In this HTTP request, there is a custom header for username and password, which is where I pass in the u/p info. If the user is authenticated, then they send back an 'auth cookie'. I'm trying to understand a few things:
What exactly is this auth cookie? Is this a standard thing? or all it means is that its a cookie that has authentication information?
The HTTP request is sent to a domain which is different than mine. i.e., the script that sends the request is on a.com and the URL where I need to send the HTTP request is b.com. The vendor is saying that I am supposed to just 'send' the cookie they return in the response back to the user. This is not working, but I need to understand why - what will the domain of the cookie be? Will it be a.com or b.com? If its b.com, will that work, because the script that is actually making the call will be in a.com, and most browsers don't allow third-party domain cookie. Or is it failing because I am trying to write a cookie with a.com, where the cookie already has data for b.com?
Figured this out. The HTTP returned is just another custom header value, and not a cookie. So, we have to write our own cookie. However, obviously, the other domain doesn't recognise the cookie. So we actually build a reverse proxy in IIS, so that the domain a.com accesses the site through the proxy, called x.a.com, and never see b.com. So the cookie written is recognized by that domain.
BACKGROUND:
I'm using two MVC3 websites for mixed mode authentication. I'm authenticating a person using windows authentication in Site1, and then forwarding that person onto Site2 which uses Forms authentication. My solution was to gather user information in site1 once the user is authenticated via windows auth. I would then write this info to a cookie, and then redirect to Site 2. Site 2 would then use the info found in the cookie to automatically log in the user using Forms Auth. Both applications are in the same domain and should be able to share cookies, however the cookie isn't available after the redirect until the page is refreshed or by clicking on a link in the site (visiting a 2nd page).
Anyway, here's my problem. I create the cookie and then forward the user to Site2 from Site1.
...{cookie created here and added to response}...
HttpContext.Response.Redirect("http://site2.mydomain.com")
When I do this, there isn't a cookie in the request. However, once on the home page of Site2, I can hit refresh, and then my cookie is part of the request and my authentication works.
I need my Response to write the cookie to the client, then get that cookie added in the request, but it seems to skip that when using Response.Redirect...
UPDATE:
I've read that the request will only have cookies included when the cookie exists before the request is made. Since I'm writing the cookie into the response for the request, only subsequent requests will contain the cookie. So, what I need is a way to force a second request, once they get my response from the initial request. So...
User sends request ---> response returns with cookie ---> force another request (should contain cookie) ---> return requested page.
Can I do this using javascript? Can the javascript check the response for a cookie of a certain name, and when found, cause a redirect to the current page?
If you have to force the refresh to get a second request, you could perhaps append a Query String parameter from Site1's redirect HttpContext.Response.Redirect("http://site2.mydomain.com?refresh=1"), then in Site2, cause a redirect to the same page sans query string parameter.
That's not really ideal though. Could you put that cookie information into a query string for a one off authentication URL that then stores a new cookie and redirects to Site2's homepage?
The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.