Le 25/09/2014 08:03, Zhang, Zhengguang a écrit :
Hi, Patrik
Thanks for your suggestions about this feature, please check my comments below.
        b). If no service is currently connected, and if userB wants to
connect a service which is favorite to other users, it must input
passphrase to connect it.
This is not possible. Either userB gets to use userA's service or then not. The
Agent API is not consulted for a passphrase, as one has already been
provided.

Do notice that it makes absolutely no sense whatsover for this kind of
convoluted use case. If userB does not know the passphrase, he's not
supposed to use the service anyway. If userB knows the passphrase and
therefore is supposed to know the passprase and is allowed to use the
service as a result, there's no point in asking it as it was already provided by
userA. So an existing service is either allowed for userB or then not; re-asking
the passphrase is not a meaningful task in this context.
My understanding is that this requirement is for the use case below:
UserA login and input passphrase to connect the service successfully, then this service 
becomes favorite to userA, then userA disconnect it and logoff. Then userB login, the 
requirement means userB can't connect to this service if he doesn't know the passphrase, 
which is just as the requirement description: "credentials given by UserA to connect 
to the access point AP should not be re-used by UserB to connect to this access 
point." Without this limitation, even userB doesn't know the passphrase, he will be 
able to connect the service successfully without authorization.
Patrick,

please remember that in parallel we are working with the security team to limit access to established network connection.
Another question:
If we use session to implement multi-user requirements, then upper layer must call 
session interface to implement it, is it possible that upper layer call service API 
directly to bypass the multi-user requirements? We find that there is a 
"SessionMode" in the manager, but it seems it doesn't work, so how to control 
that upper layer applications must follow multi-user requirements?
We have the capability to stop any call to by pass a layer if we wish in Tizen. Each application has a unique Smack Label which can be propagated in the system with the user ID.
So bypass can be stopped.

Dominig
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to