|
|
Thanks all for the responses.
I think Mark’s suggestion is the approach one would have to take to avoid the scenarios described by others regarding locking users out: i.e., to invalidate previous sessions with a new login as opposed to denying
new logins.
Mark, I’m going to pass this on to our dev team. Please excuse my lack of knowledge, but is checkAccess() a method provided by WebObjects or would that be a custom piece that you’ve written / we would need to
write? The good news is we already track sessions in our database, but other than tracking logins/logouts, there is no connection between sessions stored within WebObjects and the sessions in our DB. So the question is where would we inject code during the
login process to update our DB to deactivate previous sessions and where would we inject code that would be executed for each subsequent request to check the DB that the session hasn’t been deactivated by a new login?
Any additional guidance on this would be very much appreciated.
Leigh Kivenko
| Chief Technology Officer
t. 416-479-0523
| e. leighk@portfolioaid.com
PortfolioAid
|
website
|
linkedin
|
twitter
166 Pearl Street, Suite 200, Toronto, ON M5H 1L3
2020 WealthTech100 Company
| 2020
WP Awards Service Provider of the Year (finalist)
This e-mail may be privileged and confidential. If you received this e-mail in error, please do not use, copy, or distribute, but advise me immediately
(by return e-mail or otherwise), and delete the e-mail. PortfolioAid is committed to taking all reasonable measures to safeguard your confidential client
information. When sending attachments and/or screenshots to the PortfolioAid Help Desk or other PortfolioAid personnel, we kindly remind you to omit,
redact or securely protect any personally identifiable client information (e.g. name, address, SIN, date of birth, etc.)
From: WebObjects & WOnder Development [mailto:webobjects-dev@wocommunity.org]
Sent: Wednesday, February 03, 2021 11:47 AM
To: WebObjects & WOnder Development <webobjects-dev@wocommunity.org>
Subject: [WO-DEV] Re: [EXTERNAL] [WO-DEV] Re: Question about (not allowing) multiple simultaneous logins
We do something like this for some apps. The trick that allows it to be a robust setup for us is, instead of denying the new login, to only allow the most recent login. In other words, if they log in to a second window, the next action
they try in the earlier window will return a message saying they’ve been logged out because of a new login.
Of course, we have to store in the database the most recent login info. (I use checkAccess() and a local timestamp to limit checking to every minute or so, just to limit DB calls.)
Hope this helps!
-- Mark
|
Security First:
External email, use caution clicking links or opening attachments
|
I once had a similar requirement. I came pretty far by
1. implementing a lock in the database
2. making sure to remove the lock during logout
3. overriding Session's terminate() method, e.g.
public class Session extends ERXSession {
…
@Override
public void terminate() {
if (!isTerminating()) {
database.removeLockFor(currentUser);
super.terminate();
}
}
…
}
That’s an unusual request so without understanding why someone would require such a thing, the basic implementation is going to have the same properties...
You’ll need a toggle in your central store (database) for that user. This toggle must reliably know if there is a session open, and this you’d likely toggle in session awake and asleep when you have an authenticated user.
Of course, you’ll run into the possibility that your session is stuck, lost to the user (like, if you left a session open on your phone and have no idea, you’d get locked out which in most cases is a critical failure of your service!) or otherwise you ever
lose track of that “off” part then your user would be locked out indefinitely and so on.
I think to understand how to approach that, you’d need serious details around the definition and purpose of the requirements because on the face of it, that’s just an idea that has serious consequences and it’s hard to imagine a value to balance that weight.
On Feb 3, 2021, at 9:05 AM, Leigh Kivenko <webobjects-dev@wocommunity.org> wrote:
Hello,
Our application is currently built with WebObjects/WOLips and in some capacity, Wonder.
We are being asked to not permit multiple simultaneous logins for the same user (i.e., on different computers or using different browsers on the same computer).
Has anyone ever implemented something like this? Is there something that WebObjects provides out of the box or do we really need to build our own custom implementation?
Thanks,
Leigh Kivenko | Chief Technology Officer
t. 416-479-0523 | e. leighk@portfolioaid.com
PortfolioAid | website | linkedin | twitter
166 Pearl Street, Suite 200, Toronto, ON M5H 1L3
2020 WealthTech100 Company | 2020 WP Awards Service Provider of the Year (finalist)
This e-mail may be privileged and confidential. If you received this e-mail in error, please do not use, copy, or distribute, but advise me immediately
(by return e-mail or otherwise), and delete the e-mail. PortfolioAid is committed to taking all reasonable measures to safeguard your confidential client
information. When sending attachments and/or screenshots to the PortfolioAid Help Desk or other PortfolioAid personnel, we kindly remind you to omit,
redact or securely protect any personally identifiable client information (e.g. name, address, SIN, date of birth, etc.)
#############################################################
This message is sent to you because you are subscribed to
the mailing list <webobjects-dev@wocommunity.org>.
To unsubscribe, E-mail to: <webobjects-dev-off@wocommunity.org>
To switch to the DIGEST mode, E-mail to <webobjects-dev-digest@wocommunity.org>
To switch to the INDEX mode, E-mail to <webobjects-dev-index@wocommunity.org>
Send administrative queries to <webobjects-dev-request@wocommunity.org>
|
|