[Seaside] abstract component with authentication check?

[Johan Brichau]

Ivo,

If you want to check on every request, I guess this is because you have both freely accessible and restricted components in your application _and_ you only want to ask for authentication the first time the user accesses a restricted component? However, doing this check during the rendering of the component will not allow you to pass control to a login component in the same way as #call: passes control. Moreover, #call: can indeed only be sent in a callback, not in the rendering code.

If you want to prohibit the display of restricted components in the rendering phase, then I think custom visual decorators are indeed the only option. But if some components are embedded inside others, the login component will simply display in their spot of the webpage. That might not always be desirable. 
Making custom request filters is an intriguing option to look at but I have no idea if the session is available in filters and if you can redirect to a login component from there. I'm also not sure if they are intended to be customized.

Now if your application does not need both authorized and non-authorized components, you do not need to check at every request. The way seaside works is that every request that pertains to a single seaside session will use the same session object. If you ask the user to login on the first request (when the session object is created), you are sure that the session is authenticated for all later requests. In my opinion, the best way to achieve this is by defining a task and using that task as the main class of your application (i.e. the entry point). The task will call the login component until the user is authenticated.

Johan

On 31 Oct 2010, at 09:44, Ivo Roefs wrote:

> Hi Johan,
> 
> Thanks for your reply.
> 
> Now I realize that I want the authorization check everytime the component is accessed (rendered).
> I think this is not possible via #initialRequest nor by using WATask?
> 
> Would it be possible to write a custom WADelegation (or other decoration) which does the actual authorization check?
> If checkOK,  pass on to next,  if not render the delegate (login component).
> 
> I also encountered all kinds of "filter" methods in the code? I this something I could use?
> 
> I indeed already use a customized session as is described in "http://book.seaside.st/book/in-action/session/customize-session"
> 
> About the snippet:
> (self session mainClass new) gives me an instance of WARenderLoopMain.
> #call: was implemented on WARenderLoopMain in the previous versions, but apparently has been removed in 3.0.
> If I try to make a call in an other way, I get a message "You can only #call: and #answer: from within a callback or a Task."
> 
> Ivo Roefs
> 
> 
> 
> Op 29/10/2010 15:31, Johan Brichau schreef:
>> Hi Ivo,
>> 
>> I never did authentication thingies in Seaside2.8 but I have those running in Seaside3.0, so I can try to help.
>> 
>> What exactly is breaking in your current code? From what I get from your snippets, I have the impression such a scheme should work if it was working in 2.8.
>> 
>> Another way to do authentication, is by defining a task and implementing the flow such that a login component is shown first.
>> 
>> Btw, the seaside book has a section with an example on one way to do this: http://book.seaside.st/book/in-action/session/customize-session
>> 
>> On 29 Oct 2010, at 09:09, Ivo Roefs wrote:
>> 
>>> ...
>>> self sessionAuthenticated ifFalse: [self session mainClass new call:  myLoginComponent].
>>> ...
>>> But now after upgrading to 3.0 this no longer works. It was a hack anyway.
>>> 
>>> This seems so basic but I can't figure out how to do this.
>>> 
>>> Ivo Roefs
>>> _______________________________________________
>>> seaside mailing list
>>> seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> 
>