I have got forms authentication working in my website. But one thing I don't understand. I had a test website and a production website, both using identical database and code. When I logged into the test site, then try to go to the production one, I still need to login. Why?
I thought the login mechanism is this:
After user password is checked fine, the server insert a FormsAuthenticationTicket cookie into client's browser.
When browser attempt to go to a page that requires login, the server checks that cookie. If it is there, then it sends that page.
If my test site has placed that cookie into the browser, now that browser goes to the production site, how did the production site know "I didn't place this cookie and therefore I still require you to login"?
I found out. Because the authentication cookie is only visible to the website that inserted it. A cookie inserted by "www.mysite.com" is invisible to "www.othersite.com".
Related
I'd like to use Keycloak to have SSO between my websites and a chrome extension. I've already set up two websites that share the same session and only require the user to login once.
However, when I'm trying to add authentication to my extension using chrome.identity.launchWebAuthFlow(), it does not seem to check cookies for SSO and systematically prompts the user to login, even though I'm already logged in my other sites.
I've tried to do things "by hand" using chrome.windows.create(), and it does skip login credentials to redirect me directly if I'm already logged in from another site, so SSO seems to be working that way. Unfortunately I don't know how to catch the redirection event that occurs once login is complete and then go back to my extension, so I'm stuck on this lead as well.
Do you know if it's possible for the chrome.identity.launchWebFlow() method to check cookies and only prompt for login credentials when it detects no session cookies ?
I'm a CS student, and I've learned that (at least in most cases) sessions are stored in cookies, that's why you keep logged in even after a computer restart.
I wanted to see it with my own eyes, so I made a simple experiment. I just logged in a popular website (e.g. youtube, gmail, facebook, etc), and typed document.cookie into the the console then received the content. After that I opened a new browser, went to the same site, and paste the cookie with this command document.cookie = .... I refreshed the page, but it didn't work. What am I missing? Based on my knowledge, it should work.
For security, login cookies should be marked as HTTPonly which sends them with HTTP requests, but prevents them from being read by JavaScript. Using document.cookie in the console isn't going to show all the cookies, especially not the secure login cookies.
To get a list of all the cookies you would have to use your browser's cookie manager that shows the HTTPonly cookies as well.
We have developped a SPA SaaS and went to a soft production launch recently.
Everything was fine until one of our customers told us they had trouble using the app.
Once they open the app, the first request to our backend triggers their proxy credential prompt. Hopefully on the login request.
They have to enter their proxy credentials to let the request go. All subsequent requests are passing properly and they can use the app.
The problem is:
When they stop using the app, close the browser and then come back the day after, the persistent login tries to connect them to our backend, but the proxy credentials prompt is not triggered and the request fails. All subsquent requests fail also.
For it work again, they have to delete all app data in chrome (so the service worker is unregistered, the localstorage and cache are cleared). The next api call will trigger their proxy credentials prompt and they will be able to work again.
So is there any way for the app to know if the proxy is set or not ? Any way of triggering the proxy prompt if not set or whatever ?
I don't exactly know how those proxies work and we have zero access to the proxy settings.
It surely is something with the credentials expiration after some time but that's all we can figure out right now. Maybe we could monitor some params in the request headers ?
We are using VueJS with axios for the requests.
My guess is when user session credentials get expired, your UI is not handling redirection to login page. When the user login for the first time you should store that the user has logged in successfully in browser localstorage. If your server returns 401 error code, you can delete the flag and redirect the user to login page. You can achieve that using meta fields in router.
Check out this link on how to use meta fields https://router.vuejs.org/guide/advanced/meta.html
On my computer, can I login to my web app, grab the cookie values, and have my selenium script use it to test the web app without having to login?
Is it also possible to modify the cookie expiration after logging in on my computer so that the cookie will won't expire when the selenium tests are running?
Is it possible to avoid having to write additional selenium logic to use the login form? If not, does it raise a cookie expired exception so that I know I need to re-login?
What about testing cookieless session webapps like Meteor.js?
Using .NET I know you can set the cookies, or at least retrieve them. Try placing your cookies there.
driver.Manage().Cookies = Your_Cookie_Object_Here;
I have started maintain a number of websites that are all authenticated using openam SSO. However when one of our users sets a persistant cookie (DProPCookie) it doesn't always work.
Repro scenario is:
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Go to site B, user is presented a login page (they should be automatically logged in).
After step 3, if I delete the iPlanetDirectoryPro cookie from my browser I can login to site B fine (using the persistant cookie). It seems that the iPlanetDirectoryPro cookie generated from Site A when the DProPCookie is set doesn't work on Site B.
Note that I have tried with various permutations of Site A and B and the scenario is the same in each case.
I'm quite new to openam so any hints as to how to debug this would be great or if I'm missing something obviously going wrong please do let me know.
Thanks in advance.
EDIT:
I have subsequently discovered that the iPlanetDirectoryPro cookie returned when authenticating using the DProPCookie isn't working. So thus has nothing to do with cross domain.
Login to openam, setting the persistant cookie
Restart browser (to clear session cookies)
Go to site A, user is logged in automatically because of persistant cookie
Delete all cookies except iPlanetDirectoryPro cookie
Refresh page - asked to login
If I repeat the test but with the iPlanetDirectoryPro cookie generated by a normal login then when I refresh the page, I automatically get authenticated. (I have changed the title of the question to reflect this).
FURTHER EDIT:
Turned up debugging - am seeing this exception in the logs:
IdName is :null
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
orgName is :xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity() from IdUtils Name: null Org: xxx
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
AuthD.getIdentity: Got IdRepoException while getting Identity from IdUtils: Illegal universal identifier null.
amAuth:11/28/2012 05:11:25:750 PM GMT: Thread[TP-Processor2,5,main]
isLockedOut:Exception :
java.lang.NullPointerException
at com.sun.identity.idm.server.IdCachedServicesImpl.search(IdCachedServicesImpl.java:585)
at com.sun.identity.idm.AMIdentityRepository.searchIdentities(AMIdentityRepository.java:296)
at com.sun.identity.authentication.service.AuthD.getIdentity(AuthD.java:1453)
at com.sun.identity.authentication.service.AMAccountLockout.isMemoryLockout(AMAccountLockout.java:297)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:281)
at com.sun.identity.authentication.service.AMAccountLockout.isLockedOut(AMAccountLockout.java:264)
at com.sun.identity.authentication.service.AMLoginContext.processPCookieMode(AMLoginContext.java:1919)
at com.sun.identity.authentication.service.AMLoginContext.processIndexType(AMLoginContext.java:1846)
A quick scan through the openam code - it appears that we are not getting a username here in AMAccountLockout.java:264:
public boolean isLockedOut() {
// has this user been locked out.
String userDN = loginState.getUserToken();
return isLockedOut(userDN);
}
Persistent Cookie mode has changed in OpenAM ... DProCookie is actually not used anymore.
Posssibly you're running 'restricted token mode' AKA 'cookie anti-hijack mode' and CDCServlet does not issue a proper authentication assertion
Could be that you are running into https://bugster.forgerock.org/jira/browse/OPENAM-1002 ?
Also it could be a problem with your cookie domains, maybe site B redirects to a different domain where DProPCookie is not visible?
Ultimately we discovered that the problem was that the SSO cookie generated by the persistant cookie had no authention modules - and therefore the authentication level was set to Integer.MIN_VALUE;.
In our situation we made a slightly hacky fix to force this to be 0 instead, which fixes up the problem.
I presume the correct thing to do would be to either have a seperate authentication module for persistant cookie logins or to store the authenticating module in the SSO cookie generated by the Persistant cookie.