I'm tasked with coming up with a way to determine if a person has reached our site via using their back button (meaning they left our site and came back) and log them out if so.
I've come up with some options, but am wondering what other options I may be missing.
FYI, we do have a session state, so server-side we're covered for long absences, but they want an additional check on the client side.
option 1: set a cooking via onunload that expires in x seconds. On each page of our site, I check for said cookie. If it exists, I assume they came from another page on our site and do nothing. If it's not there, I assume they have been gone from our site more more than x seconds and redirect out. Con: Blackberry devices running OS5 don't support onunload.
option 2: same as #1 but instead of setting cookie onunload, we set it on every click of every link that goes to another page on our site. con: messy
option 3: check browser history on every load of every page of our site. If the previous URL is not one of ours, we log them out. Cons: browser support? It looks like previous/next history objects are now blocked in modern browsers due to security.
Option 4: Via JS, every x seconds, check for a cookie. If it's there, reset it to expire in x seconds. If it's not there, assume they've returned from somewhere else. Con: Not sure if the JS cookies would be set while that page may be in the background (app switching on an iPhone, or using a different tab in a desktop browser).
Any other options I should consider? Is there a 'proper' way to handle this? Is this just grasping at straws trying to prevent normal browser behavior?
You could keep the current page name/action/identifier in a session variable, then use a javascript onChange/load/keyup/keydown to request the current state of the user from the server. If it does not match, redirect or otherwise block them from viewing the current page.
This is a method that I've used, but it has it's downsides.... for example, onload doesn't always seem to work when the user uses the back button. OnChange, etc on certain form fields definitely works. Timers are pretty straightforward, as well, but a quick user can get input through the page regardless.
It's not that complicated... Use javascript history object
history.next gives you the complete url of the page in the forward button. A simple regex can tell if it's from your domain or not.
I just don't know if it's supported by all browsers
Related
I don't want to get into details of my situation, but it's like this:
I'm part of a website and so are other people. On this site, we are all waiting for something to appear on the site, but one must refresh the site to see if anything new appeared. The site rules explicitly mention that auto-refreshing tools are prohibited.
If I for example use a browser extension that would refresh the site every minute, could the site detect that? Do these extensions make the same request to the site as if I clicked the refresh button? I'm sure they could detect the refreshing intervals, but that can be avoided by a random timer. So what is the most undetectable way of autorefreshing a site?
Different extensions work differently.some use the javascript reload function, some will just grab the url and replace window.location with it effectively making another GET request
The only difference in the actual request will be whether or not cache control is set etc..so they might use that for detection.So definitely you need to take a look in the documentation to see how the request is being issued in that specific extension
As far as circumstantial evidence they can cookie you,use local data storage,use your ip address to determine you are the same user which in that case you would need to find a workaround for each one
HTML5 introduced some really neat tools to manipulate the browser history, namely the history.pushState/replaceState methods and the onpopstate event, so we don't have to rely on location.hashes to display a meaningful url for our web applications.
(Or better, we won't have to rely on hashes when the adoption of IE<10 will be negligible.)
Using the browser's back and forward button doesn't reload the page if the targeted state was created using history.pushState, even if the URL looks completely different.
However, unlike changing the hash, if the user changes the url from the browser's address bar, the browser does reload the page. Somehow I doubt there's an effective solution for this, but the question is: is there a way to prevent the browser to reload the page, and force it to push an history state instead?
I don't believe so. AFAIK, manually entering an address in the address bar - unlike clicking a link, back/forward buttons, pushstate/popstate, and form submit - is defined as requesting a new page, unless you change a hash (like in the pre-html5 days).
No. It isn't possible to interrupt the loading of new pages via the address bar (except for unload events, but they can only give you "Are you sure you want to leave the current page?" interruptions).
The real URLs should be handled by your server which should build the page into the expected state for that URL before delivering it to the client.
Is it possible to use cookies, to let users browse faster in a site with a lot of jquery modules? I mean, that every time when someone clicks browsers back button, he goes back to the page which was in it memory (every page module would be in exactly that position in which it was when user got out from that page).
You might find pushState and history useful for this: Manipulating the Browser History
Using these techniques, you can change what information is requested when the browser's back button is used.
I was just looking at this stackoverflow question: Display web browser settings
And that helps.
But, I'm curious if I can detect certain IE specific settings. I'm thinking some of the stuff in the Advanced Tab (e.g. Is 'Enable Integrated Windows Authentication' on)?
Or that our site was added as a Trusted Site? And within the Trusted Site settings, "Atomatic logon with current user name and password" is set?
I don't want to change them (I get that would be a huge issue that could be exploited). I just want to be able to present to the User:
"Hey, you need these couple of settings checked or unchecked for the site to work properly. Do this: a, b, c ... or Contact your Administrator".
Is this possible?
I don't think you can query these settings from within a web site. Being able to do so might introduce security holes.
I'm sure some settings can be determined by using circumstantial evidence (like if a JavaScript doesn't execute, scripting is probably disabled). But I don't think there is a proper API to poll every setting; I guess the best you can do is serve the user some advice on what to look for. (like, "The xyz symbol in the bottom right bar should show a green checkmark like so.... the abc checkbox in the options dialog should be unchecked... etc")
You can't check the settings directly, but you could test the functionality instead. If you attempt to authenticate with the server and find out you don't have their credentials passed in properly, you know it's not configured right. At this point you could show them your information about how to connect to the site. This would be a better solution anyways, as you're better off testing for features rather than specific settings.
To distill your question down, it looks like you're trying to find out whether IE is configured to automatically send NTLM credentials to your server.
Unfortunately, there's no way to cleanly feature-detect this. My initial thought was to put a JavaScript file in a protected directory that simply set a global variable, and link to that script in the <head>. (<script src="protected-dir/test.js"></script> – protected-dir would be configured only for integrated auth with anonymous auth off.) If the script loads, the variable is set; and if it fails, the variable obviously isn't. Another script on the page could check the variable and show a message if it's not set.
This works flawlessly when everything is configured correctly on a client, but when auto login is off, this causes an ugly 401 dialog to pop up, which is clearly no good. Additionally, a XHR request isn't the answer since the spec specifically says the browser should ask for credentials if it gets a 401.
Sadly, I don't think there's a way to automatically determine if auto login is enabled without causing the 401 dialog to pop up.
Got a window.history.go(1) to stop the user hitting the back button, but was wondering if I could check to see if a forward history exists before doing it, so I can display a popup warning the user not to press the back button.
I know you can get the history length, but is there a way to get the current position in the history list? Or some other way of doing this...
AFAIK you won't be able to access the history from JavaScript. It will be a security hole and most of the browsers won't allow that. Probably there might be a workaround in IE by using ActiveX.
Found this entry which might be useful to you
window.history
There is a next property.
Returns the URL of the next item in
the session history
This property is not available to web
content and is not supported by other
browsers.
For security reasons the History
object doesn't allow the
non-privileged code to access the URLs
of other pages in the session history,
but it does allow it to navigate the
session history.
There is no way to clear the session
history or to disable the back/forward
navigation from unprivileged code. The
closest available solution is the
location.replace() method, which
replaces the current item of the
session history with the provided URL.
Don't break the back (or forward) button.
You don't know exactly what they might do without knowing every possible user's setup (including plugins, etc.)
You still have to do something mildly intelligent (e.g. not trash your database) if scripting is disabled, or disabled then re-enabled, etc.
Because you already have to handle #2, don't even worry about figuring out how to do #1 everywhere for everyone, and spend more time to make #2 work better.
Now your site works with the back button.