crazyflx
Elite Member
- Nov 9, 2009
- 1,623
- 4,870
EDIT: If before/during/after reading this thread, you have the thought "wow, this is old", please see here:
My reply to somebody who already said that on this thread
I've been away from BHW for a very long time, and seeing as this will be my first post since "being back", I wanted to make it a good one...a really good one. So here it is:
I'm Going to Show You How You Can Tell if a User is Logged Into Virtually Any Site
Before going any further and providing the demo URL, I want to note a few things:
Demo/Example URL: http://crazyflx.com/logcheck/logintest.html
All Source Files Can be Downloaded Here: http://crazyflx.com/logcheck/
(virustotal not included since they are literally just text files)
If you ARE logged into facebook, and you attempt to browse to URL 1, you will be redirected to URL 2. In addition, if you ARE logged into facebook and you attempt to browse directly to URL 2, the page just loads as it should.
If you are NOT logged into facebook, and you attempt to browse to URL 1, the page just loads as it should. In addition, if you are NOT logged into facebook and you attempt to browse directly to URL 2, you will be redirected to URL 1.
So in scenario 1 (logged in), loading URL 1 will take longer to load than URL 2...because URL 1 has to redirect you to another location. The additional amount of time it takes is VERY small, but it's there...and is measured in milliseconds.
A couple questions you might have right now, if you're a little more knowledgeable about the use of JavaScript than most, might be:
To get around the pesky issue of "same origin policy", the script makes use of what most browsers (aside from IE) allow for...that being:
You CAN load an external URL using JavaScript by simply "saying" that it is javascript file...and it works even if the remote URL is not javascript or even text...it can be anything. Then, in addition to that, we add an "onload" event that "fires" when the remote URL has finished loading. That looks like this:
Then we "start" a timer immediately before requesting the remote URL, and then the "onload" event "stops" that same timer, giving us the number of milliseconds it took to load that remote page.
Now, browsers DO have "onload" AND "onerror" capabilities, but the problem with that is that the "onerror" only triggers on "hard" errors (like a 404 for example) and even then the target server has to be configured a certain way (this is being very, very vague, but this isn't a JS lesson). The "onerror" event is NOT triggered by a 301 or 302 redirect. This is not to mention that it is damn near impossible to find URLs that return a 404 error when logged in/not logged in. So essentially, we're using a timer to determine the status code of the URL...in a roundabout way, as.it's impossible to get the actual response code.
That answers the first question...now let's move on to the second one....about the issue of a remote URL taking a different amount of time to load even the same URL twice.
To get around this, we perform the same test (requesting those two URLs on the target site), a repeated number of times. In the demo I linked to above, it requests those two URLs on the target site 6 times each and records the time difference between the two each time. If out of those 6 tests, 4 or more return as "true", then you are logged in. Otherwise, you're logged out.
You can perform the tests a fewer number of times, however the fewer times the tests are performed, the less accurate it is. 3 tests is a nice happy medium, and if 2 of the 3 times it returns as "True", then you're logged in. Using those settings I found that it was pretty reliable. In the demo, as I have it set now, it's almost 100% every time, and if it's "wrong" it only returns that you're NOT logged in, not that you are...so no harm no foul.
My reply to somebody who already said that on this thread
I've been away from BHW for a very long time, and seeing as this will be my first post since "being back", I wanted to make it a good one...a really good one. So here it is:
I'm Going to Show You How You Can Tell if a User is Logged Into Virtually Any Site
- This only works in FireFox, Chrome & Opera - it works in Safari, but requires separate configuration for some sites - IT DOES NOT WORK IN IE AT ALL
- It makes use of browser behavior that should NOT be eliminated by programmers of FF, Chrome or Opera...now or really even in the future. It uses "standard" behavior, nothing out of the ordinary...it just does it in a clever fashion
- I have not tested it in any browsers other than FireFox, Chrome, Opera & Safari (I knew it wouldn't work in IE, didn't bother trying)
- In the demo, if you're not logged into a personal gmail account, it will assume you do not have a google plus account
- In the demo, it will check each account sequentially, one after the other, not all of them simultaneously
- The demo URL below will show your login status for the following sites: BHW, Amazon, Facebook, Reddit, Gmail (personal), Google Plus, Twitter, StumbleUpon & Flattr
Demo/Example URL: http://crazyflx.com/logcheck/logintest.html
All Source Files Can be Downloaded Here: http://crazyflx.com/logcheck/
(virustotal not included since they are literally just text files)
How does it work?
In a nutshell (more detail, for those interested, is included below), it works by using JavaScript to request two different URLs on each target site. It calculates the amount of time it takes for each of the two URLs to load. If URL 1 takes longer than URL 2 to load, then you're logged in. If URL 2 takes longer than URL 1 to load, than you are not logged in. To make this example clearer, let me give a quick explanation, using facebook as an example:
- URL 1 = https://www.facebook.com/login.php?next=https://www.facebook.com/events/lis
- URL 2 = https://www.facebook.com/events/list#_=_
If you ARE logged into facebook, and you attempt to browse to URL 1, you will be redirected to URL 2. In addition, if you ARE logged into facebook and you attempt to browse directly to URL 2, the page just loads as it should.
If you are NOT logged into facebook, and you attempt to browse to URL 1, the page just loads as it should. In addition, if you are NOT logged into facebook and you attempt to browse directly to URL 2, you will be redirected to URL 1.
So in scenario 1 (logged in), loading URL 1 will take longer to load than URL 2...because URL 1 has to redirect you to another location. The additional amount of time it takes is VERY small, but it's there...and is measured in milliseconds.
Now for More Detail
A couple questions you might have right now, if you're a little more knowledgeable about the use of JavaScript than most, might be:
- How can you request an external URL using JavaScript? "Same origin policy" prevents any requests to external URLs that are not on the same domain as the domain running the script.
- What if there is just a bit of "server lag" from the target server when requesting the second URL...server lag that wasn't present for URL 1...therefore causing it to take longer to load than the first URL even though it shouldn't.
To get around the pesky issue of "same origin policy", the script makes use of what most browsers (aside from IE) allow for...that being:
Code:
<script src="http://SomeRemoteURL.com/NotJavaScript/"></script>You CAN load an external URL using JavaScript by simply "saying" that it is javascript file...and it works even if the remote URL is not javascript or even text...it can be anything. Then, in addition to that, we add an "onload" event that "fires" when the remote URL has finished loading. That looks like this:
Code:
<script src="http://SomeRemoteURL.com/NotJavaScript/" onload="DoSomething();"></script>Then we "start" a timer immediately before requesting the remote URL, and then the "onload" event "stops" that same timer, giving us the number of milliseconds it took to load that remote page.
Now, browsers DO have "onload" AND "onerror" capabilities, but the problem with that is that the "onerror" only triggers on "hard" errors (like a 404 for example) and even then the target server has to be configured a certain way (this is being very, very vague, but this isn't a JS lesson). The "onerror" event is NOT triggered by a 301 or 302 redirect. This is not to mention that it is damn near impossible to find URLs that return a 404 error when logged in/not logged in. So essentially, we're using a timer to determine the status code of the URL...in a roundabout way, as.it's impossible to get the actual response code.
That answers the first question...now let's move on to the second one....about the issue of a remote URL taking a different amount of time to load even the same URL twice.
To get around this, we perform the same test (requesting those two URLs on the target site), a repeated number of times. In the demo I linked to above, it requests those two URLs on the target site 6 times each and records the time difference between the two each time. If out of those 6 tests, 4 or more return as "true", then you are logged in. Otherwise, you're logged out.
You can perform the tests a fewer number of times, however the fewer times the tests are performed, the less accurate it is. 3 tests is a nice happy medium, and if 2 of the 3 times it returns as "True", then you're logged in. Using those settings I found that it was pretty reliable. In the demo, as I have it set now, it's almost 100% every time, and if it's "wrong" it only returns that you're NOT logged in, not that you are...so no harm no foul.
What Sites Will This Work On?
That's probably my favorite part about it...it will work on virtually any site that has an area that is for "Members only". Since we're not relying on an actual "error", but rather are simply relying on finding pages that behave DIFFERENTLY based on your login status, it opens it up to working on virtually any site. Since almost every site that has a members area have pages that behave differently based on your login status.
Feel free to ask questions, post comments, make suggestions.
ENJOY!!!
ENJOY!!!
Last edited:
