Hi Sebi, not really.
PicketLink was designed with the concept of Agents so is perfectly possible to attach to a
single User multiple Agents or not. We've been discussing it for unified push.
In this scenario I'd like to enable/disable push notifications to an specific group of
devices. Matthias already described some use cases here
https://gist.github.com/abstractj/457b5cea09a23259159e, I'd appreciate if you could
describe these scenarios.
Would you like to authenticate a single device? Multiple devices? What's your idea if
a user try to login into multiple devices? Forbid login? Allow?
Before we start to code, let's describe more detailed scenarios. At first glance a
short answer would be, stick with Agents, but it might not be the correct answer to you.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Monday, March 18, 2013 at 8:08 AM, Sebastien Blanc wrote:
Hi Folks,
I started this thread to figure out how to handle a particular situation.
Currently when we log in into an application using ag-security-pl (and implicitly through
picketlink) and the user was already logged in, we get a
"UnexpectedCredentialException".
The Aerogear Controller Demo, for example, handle this exception by displaying an error
page telling : "user already logged in, maybe you should log out".
But I was really thinking of where relies the responsibility of handling this very common
use case (the same is applicable for the "register" flow) :
I have user Bob who has his Device A and B using Application SlackerApp :
- He logs into SlackerApp with Device A.
- While still logged in with Device A, he logs into SlackerApp with device B (for a
concrete example think of Bob using twitter on his laptop when working and his mobile when
he is at the bathroom).
In this situation, the log in flow for Device B will have to handle a
UnexpectedCredentialException, I see 3 situations for handling this :
- SlackerApp handle the exception : - by swallowing it and returns a successful log in
status, - throwing a error page (which can be strange for Bob who wants to use his app on
device B)
- AG security handle the exception : - by swallowing it and returns a successful log in
status, -throwing a http status
- PicketLink handle the exception : - by swallowing it and returns a successful log in
status, -throwing a http status
I'm just wondering what is the best way to handle this
Seb
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/aerogear-dev