Web Server - automatic logout

mgd
mgd
in SecuritySpy

v6.n It is common for web interface users to neglect logout, meaning their session can remain logged in and reconnected to without explicit credentials. Is there any mechanism to automatically logout a session either after a period of non-use, or perhaps explicitly with a page 'beforunload' enclosing an <iframe> to the SecuritySpy web service, or etc.

I have been through https://www.bensoftware.com/securityspy/web-server-spec.html and anything else I could find via search engines.

Also v6.n contains a couple of (as yet) undocumented fields at Settings / Web / Advanced / CORS domains + Public resources.

Thanks (and kudos).

Comments

  • Ben
    Ben

    You'll find an option for this under Settings > Web > Advanced Options, called "Session duration". Here you can choose the length of time that any user will remain logged in, before having to re-enter their username/password. If you don't see this option, this means you're running an older release, so use the option under Settings > Registration to update to the latest version of SecuritySpy.

    As for the other settings you asked about:

    CORS domains - defines other web server that are explicitly authorised to access resources from SecuritySpy through Cross-Origin Resource Sharing (CORS) headers. It's useful when you have a page residing on a different web server, that needs to access resources from SecuritySpy's web server.

    Public resources: defines any page/image/file for which access is to be allowed without username/password authentication.

    These advanced options aren't going to be used by the vast majority of users, however they have proved useful for the minority of users who are doing more advanced/unusual things with our software.

  • mgd
    mgd

    Thanks Ben. I can see "Session duration" under v6.10. (Have been running v6.7 this last week ... see below). Good idea.

    My current thinking is, logon credentials are cached, and in this age of tabs + multiple individual pages, if the browser is not closed the credentials remain (have demonstrated this). Can it be made to operate when the browser page/tab is closed?

    I have been running v6.7 for the last week confirming that the camera network events reported in the latter entries of ticket Q7M-BWJ-9TAU are not present under v6.7. They are NOT present. They are only present under v6.10.

    Thank you for the clarification on CORS. Thought that would be the case, and have used it to allow me to "wrap" the SecuritySpy portal in our own "Terms and Conditions" notice (wasn't an issue under v6.7). "Public resources" makes a certain sort of sense and could have possibly used it to provide our [x] T&C (see attachment). The portal is only visible/accessible once the [x] is ticked. Perhaps we are guilty of "... doing more advanced/unusual things ..."

    Screenshot 2025-05-26 at 07.30.06.png


  • Ben
    Ben

    We like it when users do advanced and unusual things with our software :)

    Web sessions work like this: when you log in, the username/password is sent to the server once. If accepted, the server responds with a session ID cookie, which the browser stores and uses to authenticate all subsequent requests. This is a standard and most widely used method for web login sessions across the vast majority of web servers and applications.

    The duration of the session is controlled by the period of validity of the cookie. This means that we are limited to the available options for cookie expiry. The available options are:

    1. Session cookies. These don't have specific expiry dates, and it's up to the browser to decide when to invalidate them. Typically, browsers invalidate them only when they are quit, not when the individual page/tab is closed (the exception to this is usually private browsing mode, where the session cookies are cleared when the page/tab is closed).
    2. Persistent cookies: these have specific expiry dates that are set by the server.

    There is no option for the server to tell the browser to specifically invalidate the cookie when the page/tab is closed.

  • mgd
    mgd

    Webby stuff is just a pastime to me (and mostly knowledge from some twenty years ago) so anything I suggest should be considered such.

    Surely an HTTP cookie can be expired by reissue with an expiry in the past?

    This could be activated by a 'beforeunload' event, perhaps using a setTimeout() to defer execution of an XMLHttpRequest() or some-such contrivance.

    https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event

    https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

    Haven't actually tried anything remotely resembling this. And probably not without limitation(s).

    I'm sure you have heaps of time to play around with such... 8-)

  • mgd
    mgd

    Having a quiet day I decided to experiment with 'beforeunload' and cookies. Seems doable using just JavaScript. Tested OK against up-to-date Edge(/Chrome), Firefox, Safari. Works for page/tab closure and for reload.

    I added <script src="./bickie.js"></script> to the previous screen grab. bickie.js is attached (as a .txt).

    Demonstration is relatively straightforward. When the T&C acceptance page is accessed a JavaScript alert pops up with the current value of the cookie. First call is empty (doesn't exist). Then an alert prompts, "delete ANEXAMPLE at page unload?"; replying [OK] sets a flag true that deletes the cookie at page unload; replying [Cancel] sets that flag as false and does not delete the cookie at unload. A third alert show the cookie value after being set. If not deleted when the page is refreshed the cookie value "ANEXAMPLE" is still present on the first alert. If deleted then empty.

    My thanks to all whose code fragments I plagiarised. Have fun (I did) ...

    bickie.txt
  • Ben
    Ben

    Using beforeunload is a good idea, but I don't think this will work reliably. Clearing the cookie can't just be done on the client side (because it's an HTTP-only cookie for security, and therefore inaccessible to JavaScript), so a request has to be made to the server to do this. From my research on this, making server requests within the beforeunload callback is unreliable since there is very limited time before the browser completely unloads the page and shuts down any activity.

    I think your best bet here is to simply set the login session duration to 1 day. Do you think this would work sufficiently well for your purposes?

  • mgd
    mgd

    Ok Ben. You've obviously given this a lot of thought.

    My use-case calls for a much shorter time-frame than days. Perhaps as little as one hour would work. Our users are very sporadic and it's just so the next time the site is accessed it doesn't spring into life automagically.

    Thanks again. (I did have fun :-)

  • Ben
    Ben

    I'd be happy to add some shorter session timeout values if it would help - e.g. 1 hour, 6 hours, 12 hours?

  • mgd
    mgd

    Very good. Ta.

  • Ben
    Ben

    Great. These extra options have now been added to the latest beta version of SecuritySpy (currently 6.11b4). Please report back with your thoughts once you've had a chance to test.

Categories