I know from questions like this one that there's no "official" way to log out of an HTTP auth "session". I've also read about the 401 header trick, but that does't seem to be too widely supported.
Now my home router, on the other hand, uses HTTP Auth, and it works perfectly! I type in my routers IP, and no web page is rendered. Instead I get an HTTP auth login box (I also have an industrial firewall at work that works this same way). How do devices like this handle HTTP auth "sessions"?
Or am I being tricked into thinking it's HTTP auth, because there's no webpage rendered, just a login box identical to one that HTTP auth uses?
The credentials for HTTP Auth/Digest are only stored until the browser is closed. If you were to login to your router, close the TAB, then go back to your router, you will see that you are in fact, still logged in.
Now if you were to log into your router, close the BROWSER, re-open the browser, and navigate back to the router IP. You will be greeted by the HTTP auth login box again.
Related
I am new to HTTP requests and I am trying to send a GET request to the login page of Oracle Apex Developer which is on a private company server.
I think the browser uses cookies which can expire because when I try to access the URL in the browser (substituting the servers IP as host name), then I first get a prompt to enter my company SSO username and password. This works fine and I can then get the page in the browser. I am trying to replicate this in python but nothing is working for me. I have even tried using HttpNtlmAuth but to no avail.
I could not see anything in Chrome network tab to indicate what the browser is doing and I have tried to simulate most of the HTTP headers in my python code (see picture below)
Here is what the browser was doing once I entered my username and password to get the 200 status code:
Any ideas what I am missing here?
Thanks
I'm making http request from React to our API for authentication. I'm using fetch to make the requests.
My question is, can a user go to the network tab in chrome dev tools, find the request, and see their own token?
It depends.
Normally, user can see all request headers in the HTTP request, in Network panel of Chrome dev tool.
However, after Chrome 67, a new feature named "Site isolation" was introduced, and enabled by default. As a result:
In Chrome's DevTools, cookies and other request headers are not shown in the network panel for cross-site subresource requests.
That is, if JWT token is transferred by cookie in a subdomain site, and the domain of JWT-cookie is wildcard, it will not be displayed in Network panel.
Here is an example. cookie token's domain is .miaotest.com, and it is used in HTTP request to site cshao.miaotest.com. While this cookie is transferred to backend successfully, you won't see it in "Request Headers" part in dev tool.
Cookie token's information in "Application" panel:
Cookie token is sent but not displayed in Network panel:
Please note the "Site isolation" feature can be disabled by visiting chrome://flags/#site-isolation-trial-opt-out in Chrome.
Yes, he can see the whole request including all request headers.
The situation is:
User is on site http://foo.com/ in one browser tab
This site needs to have a link/button that will open https://bar.com/ in a new tab
https://bar.com/ uses basic auth, and foo.com wants to automatically pass those credentials, such that the user is not prompted by the browser.
The obvious answer here is to pass the creds in the URL, e.g. https://user:password#bar.com. Unfortunately, this good old syntax doesn't work in all browsers (doesn't work in the latest IE).
I'm looking for an alternative that would work across all major browsers. e.g. potentially something along these lines:
The foo.com page builds the Authorization header (by base 64 encoding the creds, ...)
Somehow inject those headers into the request that gets sent to https://bar.com/, such that the request gets authorized with no user prompting.
Even if you are able to achieve sending the credentials to the site on the first request, unless the browser knows the contents of the credentials, it will have to prompt the user again for these credentials if the user navigates to another page on that same (bar.com) site that is protected by basic authentication.
If you have control over the bar.com site, then you might consider an alternative authentication scheme that uses a token generated by foo.com, which bar.com then interprets and, if valid, initializes its session to look at a cookie instead of requiring basic authentication for future requests.
Take a look at this question and this one.
I have a site (running a 3rd party app) that's available over HTTPS and HTTP. It allows people to log in with Basic Authentication. I'm trying to force all logins to happen over HTTPS rather than HTTP.
The app is odd in that the authentication "realm" is the root of the domain (/), and 401s are returned based on query string parameters rather than the URL path. I think I've got my RewriteRules set up properly so that any request that could result in a 401 is redirected to HTTPS first. However, I'm worried that after logging into the secure site, if users navigate back to the HTTP version somehow, browsers will still send Authorization headers (now unencrypted) without seeing a 401 since it's all the same domain with the /same/path/structure. That is, I'm worried about this behaviour from RFC 2617:
A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
Should I worry? Or does switching protocols (https to http) prevent browsers from sending those preemptive auth headers?
We heavily use basic auth for our application. All using https of course :)
Browsers have a good sandbox model, they know that when the protocol changes, the target machine may not be the same anymore. You don't have to worry about browsers submitting the authentication information.
Even when they run into the initial 401, they will still ask the user for the username/password pair.
I have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.