Developers of Sympa

[Olivier Salaün - CRU <address@concealed>]

Hi John-Paul,

John-Paul Robinson wrote:

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

Exactly.

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"
  

Actually it appears that the previous action is never used when using 'generic_sso', because of the 'return home'. We should have a "return $in{'previous_action'} || 'home' " instead

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

It is confusing. The name of this parameter was related to our first needs : keeping track of the previous action while performing authentication, so as to return to the desired page eventually.

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.
  

Here is how you could add this feature I name here "collect_email" :

1. At the end of do_sso_login(), replace the return 'home' with a "return collect_email"
2. Add a do_collect_email() subroutine + entries in %comm and %action_args
3. The do_collect_email() subroutine will be called in 3 steps :

1. It will provide an empty form + required instructions
   
2. It will recieve data from the form, send a confirmation request and request the user confirmation
3. It will recieve the confirmation data, check it, register the email address and send the user to the "home" page or somewhere else

Add a web template "web_tt2/collect_email.tt2" This template should include conditionals to detect what is the current step (initial form / confirmation request). Note that you don't need data in the template for the third step (collecting performed) because you will just throw the user to another action ("home" for example) The connection between the action and the template is name-related and automatic. All you have to do to parse the collect_email.tt2 template is to perform a "return 1" from within the do_collect_email() subroutine.

[...]

I was hoping to construct URLs like 

  /sso_login/<service_id>/requestemail/sso_login_succeeded

and

 /sso_login/<service_id>/validateemail/sso_login_succeeded
    

I mentionned "collect_email" but "request_email" is just fine.
The receip below allows to have a single action+template for the whole process but you can separate "request_email" and "validate_email" if you wish. Both methods are used in wwsympa.fcgi.


Let me know if my explanation are unclear or uncomplete.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature