Developers of Sympa

[John-Paul Robinson <address@concealed>]

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

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?

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.

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. 

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).

Thanks for any further insights.

~jpr