JWT authorization is implemented on the store's website, tokens are stored in localstorage (I know that the implementation is not the best). After making the payment, the user returns back to the site and the localstorage is empty. If you make the payment again, then everything is fine.
This problem is present only in a private window, and only in the Chromium browser. In other cases, everything is fine.
I know that chromium is trying to protect the user more correctly. But why is this happening? And why do the second and subsequent times (before closing the private window) work as usual?
Related
I have a web application and we are calling a third party to process some data. Once it's done, the third party will redirect back to my application (It's a post redirection). To keep the session, we are using cookies. After the google chrome update, where the default values for samesite=Lax, I've updated our cookies to pass as samesite=None; Secure to overcome this issue. Now after google chrome version 91, this implementation is not working and I'm getting a session expiry issue. Can somebody help to fix this issue for google chrome version 91 and after? I'm using java
The best that we have been able to come up with is a client side meta refresh. When the third party posts back to our application, we have a page filter that will send it to a "refreshMeta" page similar to https://www.w3.org/TR/WCAG20-TECHS/H76.html. This has to happen without calling .getSession() anywhere because that will cause a new session to be created. This causes the page to refresh in the browser and send all original cookies back to the server because its coming from the same domain and a new session wasnt created.
I will say this worked for a while but it looks like there was change in Tomcat that's preventing this approach from working like it did on earlier versions, which is why I'm back looking for another solution.
I have the following case in a web application of mine. The usual browser that the user uses is Chrome.
I use digital certificates that users have cryptographic cards that they insert into a card reader.
To log in to the application, basically users access the https link that makes the certificate data read.
So far everything works fine.
If the user to end his session of the application closes the browser, there is no problem. Everything is over.
But if the user wants to leave his application session, without closing all browser windows, here are my problems.
There is a button that closes the session of the application, the user leaves and redirects to the initial login screen. It seems that everything has been reset, because the user has left. But when the new user wants to log in and press the link to read the certificate data, instead of doing a new reading of the new card, use the data from the previous card without just asking for the pin to access it.
The problem goes further, for example, if the user has forgotten the card, the card and tries to logarize, the failure to read the certificate. But now, although inserted correctly, the card will not be read again until the browser is restarted, which maintains a cache that does not have a certificate.
At the moment only the solution was found by closing all Chrome windows, but that depends on whether the user does or not.
A partial solution would be sure to close the browser with javascript () but for some time, it can not be closed with javascript (window.close ()), a window that can not be opened from the site itself, with what is available I think it's ruled out
Can someone contribute to me? Thank you
Chrome and the rest of browsers maintain a cache of the SSL authentications performed and decide when to prompt user for selecting a certificate. There is no "logout" function neither the connection can be closed from server side due to TLS resumption protocol ( client can resume the session)
This a common and known issue when defining an authentication system using client certificates. I only have found a workaround: use different domains to force browser to choose a certificate:
login.domain.com
-->login1.domain.com
-->login2.domain.com
-->loginN.domain.com
You have a virtual authentication URL login.domain.com which redirects user's browser to a random loginN.domain.com every time you need an authentication. Chrome will detect that it is a different domain and will prompt user for selecting a certificate
You could also think about using different ports instead of different DNS, but then you could have problems with the user's firewall because you are not using a standard port, and in this case Firefox does not show the window either.
Please I developed my mobile app and is primarily using localStorage for storing account info and some other info. The app has mobile and browser version.
For the browser version, I expect a user that is logged in to not be redirected to an auth page on browser restart. This works fine as my info are stored in localStorage. On the other hand, my mobile doesn't. User have to log in whenever he restart the app.
Please what option do I have? What option do developers use for the mobile storage? Do I have to use database? If so which one should use and where can I find a better documentation on this topic?
Note: I am using Cordova for my mobile app development framework.
For some reason, localStorage is tied to browser history. Some mobile browsers have an option to erase browser history on exit. If that box has a checkmark in it, then localStorage gets purged along with browser history everytime the browser is closed! So, you can ask the user to go into Settings and uncheck that box. Note: localStorage is not supported by older IE browsers, Opera Mini, and some Blackberry devices.
If cookies are enabled, you could use a one-time cookie code to log the user in automatically, but that cookie must expire after first use. Once the user is logged in, the server must issue a new cookie code to the client. And the client can use that new cookie to log in once again or keep alive the session. Using the same cookie twice should not work for security reasons. And the server must make sure never to issue the same code to two different users!
I remember, about 10 yrs ago, I went online to check my emails, and immediately the site had me logged into another user's account! I could have read that person's private emails and stuff, but I decided not to. I reported the incident to the admin. The problem was probably their server issued a random quick-login access code to me, and another user somehow got the same access code that I got. And when I opened the website, it thought that I was that other person. If your site deals with money and credit cards, you should avoid this technique! Any kind of auto login is a bad idea for a bank!
There is a plug-in to store data in an SQLite database using Cordova in this link
. You can find more details about storage with Cordova in the doc.
Save your data by using the following:
localStorage.setItem("variable", value);
Retrieve it from localstorage by using the following:
localStorage.getItem("variable");
It is as simple as it is.
Reference here.
SharePoint 2013 doesn't use Session cookies by default, but rather persistent cookies. Based on several articles, including this one, you can force SharePoint to use session cookies by the following PowerShell command. I ran this command in my SharePoint environment.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
My goal is to make a user re-authenticate when they close and re-open their browser. For both Forms Authenticated users and Windows Authenticated users, this works great in Firefox and IE. However, in Google Chrome, when I close/re-open the browser and navigate to my SharePoint site, it remembers the user that I was authenticated as before I closed my browser; which is baffling, considering this is supposed to be a Session cookie. This happens for both Forms Authenticated users, and Windows authenticated users.
FedAuth Session cookie, given by SharePoint, as seen in Chrome
Any ideas why Google Chrome (but not IE or FF) is "remembering" my credentials upon browser close/open?
SharePoint Version: 2013, on-premise.
Chrome Version: 42.0.2311.152
Other Notes:
WindowsTokenLifetime is set to it's default value, 10hrs
FormsTokenLifetime is set to 2 minutes
LogonTokenCacheExpirationWindow is set to 1 minute
Update:
I tried closing all identifiable Chrome.exe processes via Taskmgr, but the next time I opened my browser, it still remembered me. However, I restarted my computer, opened the browser, and it didn't remember me that time. I don't think this is a SharePoint issue, but rather a Chrome issue. My guess is that some Chrome process is staying alive somewhere, even though it appears to be closed, thus allowing the "Session" to remain open. Still investigating...
Apparently, when you let Chrome run in the background, the Session cookies aren't expired (even though you've closed the browser). Disabling background mode causes Chrome to forget your Session cookie, as it should.
Note: I'm curious if this a bug in Chrome. This behavior seems to go against what a Session cookie is.
a cookie that is erased when the user closes the Web browser. The session cookie is stored in temporary memory and is not retained after the browser is closed
Update:
According to Google, this is expected behavior (though I'd consider that notion debatable). Also, another SO user also came across the same issue.
I spent the day debugging my website, because I seem to be getting randomly logged out, but just on Chrome on Android.
After reviewing the server logs, I see requests from my Android tablets IP hitting my server for links that I never clicked on. After some experimentation I see every couple of links I click, Chrome will fetch another link at random in the page that was not clicked.
The issue is that there is an a link in the page with an href="logout" which will sign in, and Chrome calls this all on its own, disconnecting the session. I suppose if I changed the link to call a POST operation Google would not fetch it, but I can't see why Google would be fetching links that were not clicked.
This is very odd, and does not occur on Firefox, or Chrome on Windows.
Not sure if this is some sort of virus on the tablet, or some thing Google is doing to check the content of pages that it would not have access to without the session.
I have seen Google do this before, but only when there were Google ads in the page, then Google would fetch the links twice so that it could get the page content to choose the ad. This seems a huge privacy issue, as Chrome is fetching private data from the session.
So the issue is that Chrome is using a new feature "prefetching".
This is a "feature" that will have Chrome randomly fetch any linked URL from the page.
This seems like a very error prone "feature" for Chrome to enable by default. Seems like it could give the user cached or stale data, or change the server's state causing obscure difficult to debug issues. This will also use double the amount of the user's data (and server's CPU), which you would think would not be desirable to most users that pay for their data.
I confirmed this by disabling the feature in Chrome.
My solution was to switch the logout call to use a POST through a element.
See, https://www.technipages.com/google-chrome-prefetch