Cookies not working with Trusted Web Activity (TWA) - trusted-web-activity

My twa works correctly but cookies not working.
I have created a remember me login, if I use the browser or pwa works fine and cookies are created. Is it possible that twa does not work with cookies? I have seen other twa's working with remember me login, how do they do it?
//PHP cookie
$timeCookie = time()+ 60 * 60 * 24 * 31;
setcookie('token', $token, $timeCookie);

A Trusted Web Activity is just a special browser tab. Cookies works exactly in the same way as in a regular browser and no special handling is necessary.

Related

Using the same login session in a different browser by copying cookies doesn't work

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.

How does a server distinguish a FormsAuthenticationTicket cookie (C#)?

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".

AbpSession.UserId return null after login

I used Asp.Net Zero (Asp.Net Boilerplate framework) in a project.
There is a problem on Chrome (some computers) and Internet Explorer (all computers) :
When authenticating with login information, the response returns with success.
But when redirect from login page to the app, auth-guard.service check current login information. This time, the application tries to get UserId from AbpSession and returns null, also page redirect to the login page again, although login was succeed.
Can anyone help me? Thanks.
Check your browsers whether they accept cookies.
When you login, you have to see the at least Abp.AuthToken and enc_auth_token cookies. You can use EditThisCookie editor to see your current cookies easily.

selenium: use my local cookie to test website behind login?

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;

SSO cookie not working when using persitent cookie in openam/opensso

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.