Antonio Gallardo wrote:
Hi:
There is another important request for flow. Some people ask for security reasons (example banking software) to allow people only login from one computer at once.
There are 2 scenarios:
1- You are logged in computer A, in order to log in computer B you need to go to computer A and do a logout.
The nature of the web gives you IMHO little to assume about the discipline of any user to be actively logging out (or on a technical level: the stability of his browser/OS for that matter)... so you'll be hitting session time-out wait periods with the first approach?
2-You are logged in computer A, if you log in computer B your session in computer A automatically end.
Hm, I have to think about 'automatically end', the fact is that the client's browser on computer A will still have his session id and it will be used in the event of the next click...
The question is what would you want to have going on in that event?
In order to do this we need access to some global store of open sessions to check if there is already a session for the given user.
I understand no everybody needs this but this will be soon or later a request for many of us.
My associating mind might be way off topic here, but I couldn't help thinking the following:
there is a number of use cases I started thinking about while thinking wild about the generalized flow concept...
the whole idea of generalized flow almost boils down to snapping the essence of current flow from the POV of the sitemap:
AFAICS the sitemap sees 2 types of URI's (with respect to flow)
1/ URI's that identify a 'use-case' or 'set-of-interaction-steps' or maybe the word is even just: a 'flow' to be _started_ ...
consequence of this starting is that a URI of the second set is made available:
2/ URI's that identify one of those dynamically created, stateful, server side objects which are able to follow up or _continue_ the flow (next steps in the use case)
(the sitemap also has typically different matchers for these two kinds, and the subsequent split semantics between @function vs @continue on the map:call seem to assert my proposition)
now, when considering access control to URI's I'ld like to make the folowing observations:
1/ the world without continuations has left us to believe that the control of user -> role -> access -> uri can be mapped in a set of static ACL's
(well I might be off scale here, I just haven't ever seen anything else applied in my experience)
2/ however the second set of URI's (the dynamic ones) disclose the need for an access control that is oriented to use-case-instances rather then to use-case-types...
the compelling use cases I saw where the folowing
-1- classic-session-tied: the instance is only accessible from requests with the same session-id as the request that instantiated the instance
-2- classic-user-tied: the instance is accessible from requests with the same user-login (as stored in the session) --> this would allow for the same user to continue his interaction on computer B even if he started it on computer A (and yes, also pick up his interaction from the same computer in the event of a crash of his system)
-3- basic-plus-superuser-role: then the instance also becomes accessible for any user with super-power role...
above is the use case of help-desk-assisted form fill in (which I mentioned before): user X fills in form, needs help, calls to the helpdesk of the company providing the service, the helpdesk clerk steps in to continue the use case, user X just presses refresh on the 'echo and confirm page', thx for the help and agrees by submitting the final step
-4- basic-plus-enduser-control: the instance is accessible to the user that created it (strategy 2) and the use case itself allows him to add allow other users in
this last one would enable something like a chatroom
(which brings us to having locks an synchronizations in the show, but that is another lingering wild thought)
-5- yours-here: there must be more, but can't think of any at the moment
I do understand that all of this could be totally driven by storing the controling meta-data for these effects in the back-end itself
(IMHO deciding to do so however pushes these concerns up into the business tier, where they don't necessarily belong?)
I know we already discused it sometime ago and there was no answer to this. The only answer was a custom authentication subsystem.
missed that, any pointers to this discussion?
I'ld have to conclude also at this time that managing the access control to the 'instance' is indeed under the realm of the use case itself,
however, I do believe that there is a high likelyhood of having ONE strategy for all use cases in a given application and even that there are only a limited set of strategies conceivable/useful when considering the set of 'all' applications
(I'm aware of the contradiction between 'limited' and 'all' but I guess you know what I'm trying to see)
so while under control of the instance, I would find it logical that some delegation pattern would be used.
Best Regards,
Antonio Gallardo
Please understand that what is above are to be considered as wild thoughts (see Sylvain: not domesticated thoughts)
-- hoping they were not so wild that they couldn't be folowed (just ask to clarify on specific spots)
-- there is no other goal then to feed discussion first and hopefully ever domesticate these thoughts :-)
-- the long due future of which strategy's will be used and maintained will depend on which itches are felt by who IMHO
-- the decission of where/how to solidify the concern in the flow is probably subject to that long way future, however the stress on design is that the outcome is to be available a lot earlier...
up to us to manage the incremental iterations (and refactorings) towards the final goal
(I am nowhere near making a first draft, but hopefuly the interaction with other ideas will get us there)
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
