Today I noticed that our company's on-premise Azure DevOps server displayed this odd behavior. When I opened the DevOps web dashboard (through our internal domain) in Google Chrome's incognito mode, it showed me being logged in, even though I made sure I hadn't logged into the website through incognito beforehand. I then tried manually deleting the cache, cookies, session data and everything else I could find and it still kept me logged in. This behavior doesn't occur when tested with Firefox's Private Browsing mode.
When logging out of DevOps the "right" way (e.g. by clicking the Log Out button), you get a message saying: You must close your browser to complete the sign out process. which might have something to do with this whole thing. If you don't close your browser and go back to the DevOps web dashboard, you just stay logged in.
My question is if anyone knows where the session data for the Azure DevOps web dashboard is stored and how they managed to implement the logging-in system this way?
Solved it by watching the network traffic in Chrome. It sends a NT LAN request which is apparently a Microsoft proprietary authentication method. That's why deleting session files or using Incognito does nothing.
Related
I have a sveltekit webapp using pocketbase that stores the authentication in cookies. If I use the browser on android normally, opening page and going to the vercel deployed page the authentication cookie works normally. If i close browser, clear tabs and everything if i come back it still automatically logs in. So far so good.
However when I pin my application with "add to desktop" the cookies disappear and I need to login again every time I open the application through the desktop shortcut ?
What am I missing? How can I better debug this issue?
Pretty stuck with this one. I'm using Auth0's SPA-JS SDK and it works perfectly for the most part, but on mobile when I refresh the page it logs me out.
I get the error that says "login required", but no such error when on the desktop. On the desktop, I can refresh the page as much as I want with no issue.
I am not using the dev keys anymore for my social signups, and the issue occurs on email signup as well, so I don't think dev keys are the issue either.
Thanks.
Are you using the mobile browser (eg Chrome / Safari)?
Or a mobile webview?
The latter case will always give you a private browser session where cookies and session storage are both aggressively dropped.
If you're not using the mobile browser then the other scenarios require more work. Logins via some form of the system browser work best.
Also are you using local storage of OAuth 2.0 tokens?
- if so try switching to session storage - could be related to cookies dropped due to a missing user gesture - eg Intelligent Tracking Protection
I have a web app that uses a cookie as an access token (to let users stay logged in after refreshing/closing the site/app). It works perfectly on desktop but when I try to use it on my Android phone (installing it via Chrome), for some reason it says that I'm not logged in which means it wasn't able to load the access token.
Why is this happening? Is there a difference between how cookies are handled in the browser and when starting a PWA as a standalone?
Also two little side questions, 1, is there a way to debug a PWA that's added to the homescreen (using some sort of remote debugger) and 2, would it be a security risk to use localStorage for storing the access token instead of a cookie? I realize neither is particularly safe but I read that cookies are slightly better for this sort of thing. localStorage works just fine when starting as a standalone
I have some troubles to start my WebApp with Chrome (not always).
My webApp is a simple Javascript App and it's loaded using HTTPs. The server providing the WebApp resources is using a self signed certificate that is not trusted by Chrome (same for Firefox...).
When a user starts for the first time the WebApp (or after cleaning the Chrome's cache) using an URL like https://mywebapp:8443/ui the user gets a message that the website is not trusted (ERR_CERT_AUTHORITY_INVALID) but the user can continue (it's the expected behavior).
Next, there's the issue: Chrome starts loading my webApp by getting the index.html and then the .css but it's unable to get the .js that contains the Javascript code of my webApp.
In the Chrome Development tool, I can see the response of the HTTPs request to get the .js file is "Failed to load response data".
I don't understand why there's this error with Chrome (it never happens with Firefox).
Next, if I reload the page in Chrome, the WebApp is successfully loaded and displayed.
I can reproduce this issue when I'm cleaning the cache in Chrome. If I'm not cleaning the cache the WebApp continues to work even after a Chrome restart.
Can it be due to the self signed certificates? What can be the reason of this issue during the first start? Why it happens only with Chrome?
Thanks for your help,
I guess it's due to using a self signed certificate,the newest Chrome Brower don't allowd trust self signed certificate,so your own certificate is not trust by chrome!
You can into chrome://net-internals/#hsts in brower address blank,then delete 'localhost' in HSTS list.
I was wrong, the issue was also appearing in Firefox.
I have found the root cause, it was due to the backend that uses a Kong cluster between the WebApp running in the web browser and the tomcat server that is located behind Kong.
An important things is that I'm also working in a DC/OS environment and between the WebApp and the Kong there's a marathon-LB !
Ok, the issue is the marathon-LB is dispatching the requests from the WebBrowser to one of the Kong from the cluster. Each Kong has its own self-signed certificate and as a consequence, the web browser gets responses from the same IP# signed with different certificates (since each request is managed by a different Kong).
When I configure the Kong cluster with only one instance everything work well because it's always the same Kong that is responding and all requests are signed with the same certificate.
The solution is to configure the marathon-LB with a certificate and then only this one will be forwarded to the WebBrowser instead of the Kong certificate.
So, I'm building a Guest Internet portal for a public hotspot in a hotel. This means the portal is served through a Network Access Gateway (a Nomadix) that redirects all outgoing traffic to the portal page. The portal needs to be able to set cookies on the browser so that Guests can be automatically logged back in after they idle timeout.
The Problem:
iOS4+ and OS X (10.7+) Devices have a feature called Captive Network Support. This feature continuously scans for Wifi SSIDs, connects to them, and curls http://www.apple.com/library/test/success.html to see if the device is connected to the internet. If it doesn't get the Success response, these devices pop open whats called a Captive Network Portal. This portal is not a true version of Safari Mobile and you cannot save cookies on this browser.
I would like an authoritative answer to the following question:
With client-side javascript/markup can I?
A) Save cookies within the Captive Network (popup) browser
B) Prevent the Captive Network browser from popping up in the first place without whitelisting apple.com
This is kinda the wrong site in the StackExchange network for sysadmin stuff; you may wish to try ServerFault. In my experience as a user, there are WiFi portals out there that manage reauthentication without cookies; perhaps ServerFault can help you find such.
That said, there's one possible solution in terms of iOS client-side development: There are CaptiveNetwork APIs which allow a third-party app to inform the system that it's assumed responsibility for authenticating to particular SSIDs, suppressing the web sheet. It's likely not a desirable solution, since it requires your users to install an app, but it's there.
You could try serving "http://www.apple.com/library/test/success.html" locally when ever an iOS device is detected. This will make the CNA not pop up and then the user could login through mobile safari, in which you can save cookies.
iOS 14 has a new API for work with a captive portal. Btw, Android supports it too