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.
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 have been looking around the last few days for cookies and gdpr law, and I have been busy getting OneTrust and GoogleTagManager up and running on our current website and it works just fine!
On our Cookie consent banner, we have a "Reject all Cookies" button and then we do not load our tracking and other 3rd party scripts.
We have also added a list of all cookies etc. we use on the site that we receive automatically from onetrust. Necessary cookies for the site to work are loaded even if the user clicks Reject all cookies.
So some problems I have today:
Rectaptcha:
https://measuredcollective.com/gdpr-recaptcha-how-to-stay-compliant-with-gdpr/
https://www.imy.se/en/verksamhet/data-protection/this-applies-accordning-to-gdpr/transfer-of-data-to-a-third-country/
According to these links, we send sensitive information such as IP address to another country. as well as puts cookies on google's own domain google.com
If we decide that the user must ask for consent before using Google ReCaptcha cookies and then a spam/bot allows the possibility to deny these cookies. Then you have to ask if there is any point in using Google ReCaptcha in the first place?
I interpret this as meaning that we cannot use Google Recaptcha and have to change to another Recaptcha solution like hcaptcha.com?
A / B test.
https://help.optimizely.com/Account_Settings/Enable_opt-in_options_for_Optimizely_cookies_and_local_storage
In recent months, we have prepared some things to be A/B tested on the website. We already do not have that many users on the site and have to run our a/b tests for a slightly longer period for better results. Of course, an a/b test uses cookies and these cookies are counted as analytics cookies.
But now that we have "Reject all cookies" or "deny analytics cookies", we lose quite a lot of visitors and it becomes almost impossible to a / b test.
Is a/b test dead for smaller websites in EU?
Local storage
We save personal data when the user orders a service from us, in LocalStorage.
Does the website have to tell users, what and why we save it in LocalStorage?
When a user has clicked "X" on a popup, we save it in LocalStorage so that the user does not have to see the popup every time they come into the page. This is not necessary but improves the user experience. So are it considered necessary cookies or do we have to have the user consent to it?
On A/B testing, there are ways to run them without relying on cookies, and instead use a server-server integration that doesn't send any of the user information to 3rd party websites. This is accomplished by having a rules engine run locally on your own server and then only send exposure logs to the analytics service.
If you're curious, one such service with a rule-set based engine is: https://statsig.com.
Disclaimer: I work at Statsig.
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.}
I have a flask app with a login page and connected to MySql. I usually run it on my localhost using chrome. My login's works fine. Now what i want is if i login into my app on a chrome it works fine simultaneously when i opened my app in another browser it gives again a login page which i don't need it.
I need only one login. If i logged in using chrome and if i open it in FireFox it should give me the logged in session not the corresponding login page.or just simply notify me "You are already logged in another browser, Log-out there and login Here.
Is this possible if so suggest me some steps.
This is completely not possible, since one browser does not know anything about stored cookies in another.
The common approach is to force logout on another login attempt, or, as an option, login denial if user already logged in.
Another way would be to detect logged in users in by their IP address, but this is really bad idea, since there might be thousands of users behind a single IP.
I have a very simple web page that uses the Facebook Javascript API and is installed as a tab on a Facebook page. When the page is loaded, the only thing it does after calling the usual Facebook init code is to listen to auth.authResponseChange and then show/hide various elements depending on whether the user is logged in or not.
If I load this page, via http or https in an ordinary browser session, everything is fine. The page loads reasonably fast.
But if I load the page tab in Facebook, it hangs for about two minutes. Chrome tells me that this wait is due to 'waiting' for my page. But if I watch the access log, I don't see an access request logged until just before the page displays. So it seems like Facebook is masking what is really going on behind the scenes.
I opened a ticket with Facebook, and they replied that this issue was due to my code and reproducible with any POST that contained a signed_response.
After much head scratching and experimentation, I found that adding the following two lines to the view that handles this page fixed it:
if 'signed_request' in request.POST:
pass
So clearly Django 1.3.1 is holding the HTTP session open until you actually read some POST values. Ouch.