Developers of Sympa

[John-Paul Robinson <address@concealed>]

I think I understand this better now. 

On Tue, 26 Apr 2005, John-Paul Robinson wrote:

> Could you help me understand the parsing/processing of the action sequence 
> described by the URL?

get_parameters() does the magic (with help from %action_args and 
%in_regex).

> If the url <baseurl>/sso_login/<service_id>/sso_login_succeeded/<service_id>
> comes in, how does Sympa work through it?  I know it moves from left to 
> right (sso_login and then sso_login_succeeded), but how does it know that 
> the <service_id> is not an action?

In this case sso_login is the action and the remain 3 components of the
path are arguments to sso_login as defined by %action_args.  In
get_parameters these arguments are assigned:

 $in{'auth_service_name'} = "service_id"
 $in{'previous_action'} = "sso_login_succeeded"
 $in{'previous_list'} = "service_id"

(I'm a little confused on the choice of the "previous_" prefix for the 
argument names rather than "next_")

> I see the %action_args could provide that but for sso_login it lists 3 
> arguements (service_id, previous_action, previous_list).  It's not clear 
> how sympa could recognize optional args that are missing in the url.

Again, it treats them all as arguments.

> I'm trying to determine the best (meaning easiest) way to insert two extra
> but potentially optional steps into the sso login sequence (between
> sso_login and sso_login_succeeded).  This is the "account setup wizard"  
> which does the "prompt for email"->"send passwd"->"prompt for email and 
> password" for users that don't have a confirmed email address defined in 
> the internal table. 

Maybe I could add argument definitions to %action_args for sso_login, 
though I'm not sure how it would deal with optional arguments.
 
> Right now I have news screens and function names defined and am able to 
> step through the screen, but only because the buttons direct the user 
> onto the next step.  This currently falls out of the /sso_login namespace, 
> though, because I haven't set up the POST-to-GET conversion for the new 
> forms.   I'm planning on doing this inside do_sso_login() but am having 
> difficult determining what the current (sub)action is in the GET request. 
> (POST is easy since I can just check the action statement from the 
> submitted form).
> 
> I was hoping to construct URLs like 
> 
>   /sso_login/<service_id>/requestemail/sso_login_succeeded
> 
> and
> 
>  /sso_login/<service_id>/validateemail/sso_login_succeeded
> 
> (not sure if I really should put the sso_login_succeeded at until after 
> the post from the form on the second url, but I hope you get the gist).

It seems that, with the current %action_args for sso_login, anything past 
the 3rd path element following /sso_login/ would be ignored.  So it seems 
some thinking on the argument list is in order for me.

~jpr