Re: UU: keeping track of user and his access

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Alexey Parshin wrote:
> IMHO,
>
> In current implementation of UU, one can get on the certain page only by two
> ways:
> - login page, then navigation
> - typing in the page (servlet) name
>   
... And parameters. CPPSERV doesn't differentiate between GET and POST
arguments.
> Since any page that requires access also requires some POST parameters,
> second case can't show anything useful. Therefore, "no login" redirect can
> always just go to the login page.
Yes, if we need access, and user isn't logged in, we redirect to the
login page.
>  I do plan re-organising of login functions
> this week, however.
>
> Access to the object is a totally different matter. Incorrect object
> modification request would throw the exception - and this generates an error
> message.
Correct. Mostly. Right now, for example, navigating to UMOEditServlet,
while not being logged in, displays edit form, along with the message, which
is not acceptable - it'll confuse 60% of users. They should get a
standardized
error page with a relevant info instead.
>  Also, since any object manipulations are performed with controls,
> we can always limit the controls when generate a page. For instance, the
> 'Edit' button isn't shown or disabled if user can't edit the object.
>   
You realize that this isn't real control, and will also mess up any
automated
web site testing procedures (or at least will make doing them right much
more
difficult). I'm not saying this is bad idea - in fact opposite. But it
isn't real solution
to the problem.
> 2008/11/9 Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>
>
>   
>> There is an important thing I want to change in the way
>> libui is organized. Right now every page has to check
>> for login info explicitly. Then each page does something
>> own (usually just gives an error message).
>>
>> What I think should happen in case of access error, is
>> redirect to the login page, followed by redirect back to
>> the source page, after login is done. This is in case user
>> wasn't logged in at all. If, however, user was logged in,
>> but doesn't have access to the relevant action on an object,
>> he should get a message which describes ways to get a hold
>> of such access. For example, if someone tries to edit a topic,
>> which he/she doesn't own, a message with contact info of
>> owners should be displayed.
>>
>> The first part can be achieved as follows:
>> 1. We implement UuServlet::service function, which will _never_
>>   be overridden by derived classes.
>> 2. UuServlet::service() first retrieves user info
>> 3. There is abstract virtual bool UuServlet::access(User*)=0; function
>> 4. UuServlet::service calls access(User*) function (NULL means
>>   no login info available)
>> 5. If access returns false, we save current page in session attribute
>>   and redirect to the login page
>> 6. If access() returns true, we call UuServlet::service(UuRequest&,
>> UuResponse&)
>>   (UuRequest and UuResponse classes are derived from
>> Http{Request,Response}Wrapper
>>    classes, and add ways to access User object of the session, if
>> present, along
>>    with some other request-specific info, which we might find useful.)
>> Obviously,
>>    this service function is abstract as well.
>>
>> We might be able to satisfy second requirement, by wrapping whole
>> access() and service() calls into a try/catch block, and providing
>> special UuAccessException, which can be thrown by either of these
>> functions, in case current user doesn't have enough access for current
>> action on current object. In the handler block for the exception we could
>> forward to a special CSP.
>>
>>
>>    Ilya.
>>
>>
>>
>>     
>
>
>