I'm trying to detect when someone logs in to my site from a new computer or new browser - like a bank would do. And if that happens, trigger 2FA, send an email, etc.
So my plan was to add a cookie with a Guid in it and then look for that cookie with that Guid whenever they log in. If the value wasn't there, then most of the time, it'd be a new device.
But I'm using Azure B2C and I believe it's overwriting my cookies (where I was storing my unique device id with an expiration of 1 year). So after I login, I can see my cookie in the browser. It's even there after I logout. But after I login again using B2C, that cookie is gone.
I can see that I can have multiple cookie middleware, but I don't know how to access one scheme over another when I go to update the cookie in my code.
Does anyone know of any guidance or best practices on this? Been driving me nuts.
TIA
{I've edited the question to be more clear.}
Related
I stumbled across a website a while back where it showed the privacy repercussions of logging in to Spotify using the web version. I believe it used JavaScript but I can't be too sure. Anyway, this unrelated website was able to display my Spotify username despite me not authorizing anything. If I remember correctly, it also had slots for other services that I didn't use so it couldn't show my username there.
But what I'm interested in learning about is how it managed to get my Spotify username. Not because I plan to use the method but out of curiosity with how the whole thing works. When I found out about that page/site awhile back, it spooked me enough that I started using a different browser profile specifically for Spotify going forward because of it but I never got around to digging deeper into how it actually did what it did.
Cookies save your an access token for Spotify account after to success login of Spotify.
Next time, if open your browser go to
https://open.spotify.com/
It's java-script to access from your PC's cookies,
call this API with cookies an access token, get your information.
Then display your user name in the web page.
https://api.spotify.com/v1/me
If I copy from my Chrome browser the access-token and API URL,
Then access by Postman.
I can get the my user name.
Each browser has own location to save a cookies,
if you never login before other browser, will not pick up your information.
I did not login before by Firefox.
This is screen of login.
I need to book an appointment on a website. These appointments are released sporadically and booked up quickly. To even see available appointment times, you have to login & complete a reCaptcha. If I wanted to write a scraper using Headless Chrome to continually scrape the site and notify me when a new appointment comes up, following the login flow each time would require beating the reCaptcha, which is at least non-zero difficult.
A better approach (I thought) would be to log in once manually, grab my session cookies, and then load them into Headless Chrome before making a request directly to the appointment times page. The server would see my request, see my session cookies, and respond as if the manually-logged in session had been refreshed. This is pretty much as outlined in the answer to this StackOverflow question: how to manage log in session through headless chrome?
But this doesn't work, and I can't figure out why. I get redirected every time straight back to the login page. I've tried on Chrome & Firefox, and with several other login-requiring websites (Facebook, Reddit, etc.).
How can these servers possibly discern between the original client and the one using copied cookies, when the cookies are what the servers use to identify clients in the first place?
Exact steps to reproduce:
Login to site of your choice on Chrome, let's say Facebook.
Export your cookies to your clipboard from the site using the EditThisCookie Extension
Launch an incognito window (to reset your active cookies) and import those session cookies with the same handy extension.
Navigate to the target, past-the-login-form url.
Get redirected.
Get frustrated.
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I am dealing with a ticketing system that was written about 10 years ago using Coldfusion 8. When a user is authenticated and logins, the user's information about his ID is saved in CF cookies, and the site uses those cookies to fill it the user's ID, name, etc. when the user is filling out tickets.
This application works fine in Internet Explorer 6.0 However we are slowly migrating to Internet Explorer 8, so there are some users here that already started using IE8 fulltime. We've been getting complaints from some of these IE8 users, in which mid-session, the cookies are lost/become null, and the user can't complete the tickets. Users are able to login just fine, but sometimes in mid-session, errors like "NAME UNDEFINED" appear. They don't seem to be isolated to particular tickets because I've looked at all the complaints we have, and they're discovered in all sorts of tickets. I check the logs/screenshots and sure enough, the cookie for the employee ID is null. I've searched all over the web and I can't find good fixes for this.
I thought about converting cookies to session variables, but that would be a massive undertaking and require a lot of testing.
Any thoughts? Thanks in advance.
Any chance the domain is changing? You could be switching between www.servername.com and servername.com? Unless you were writing domain cookies a change in the domain would cause the written for one domain cookies to be unaccessible from another. You can enable domain cookies in your Application.cfm or Application.cfc file. Either set <cfset this.setDomainCookies = true /> in Application.cfc or set the setDomainCookies="true" attribute on your <cfapplication /> tag. This will write cookies accessible from any subdomain.
Have the cookies expired? You can set an expiration date for the cookie. Perhaps it is expiring before the user's session expires?
Have you tried using the IE development toolbar to track the cookies? You can use it to view cookies set for your site.
In one of my application , our users are facing the same issue.It started all of sudden without any change in code.We suggest them to clear cache and tr-try and it works.But i need to know the root cause and its fix.
Thank you
I'm trying to get IE7 to share its cookies between sessions. I found that if i set the expiration date, it will share the cookies. However, i can't use this method because i am trying to control login to my application (users may only login once). Is there another way to get IE7 to share?
Thanks
As far as I know cookies aren't bound to session, but to the browser i.e. different sessions can read the same cookie (on the same domain).
A better way to check if a user is allready logged in would be a flag in the database, since users who really want to log in more then once can use different browsers...