Developers of Sympa

[John-Paul Robinson <address@concealed>]

Thanks. Yes, this helps much.

I'm specifically trying to understand the operation of do_sso_login and 
inject some new logic into the process for testing purposes.

The current logic (when using generic sso) seems to be: 

* user clicks on magic authn button which posts to /sympa (whatever home
is) with the arguments of the auth_service_name and the action sso_login.

* this causes the action  "sso_login" which maps to a call to 
"do_sso_login" to be executed in the main loop.

* inside do_sso_login the generic_sso code gets selected and, since this 
was a POST, the first block of code in the generic sso section of 
do_sso_login gets executed.  This code redirects the user to the 
http://host/base/sso_login/$auth_service_name/sso_login_succeeded/$auth_service_name
 
URL.  

* the code then sends the Location: header and returns 1.

I was confused about how the remainder of the code in do_sso_login ever 
got executed.  That is, the code which creates the account based on the 
http_email_header and also sets the attributes distributed from shib.

In writing out the above URL, though, I think I've answered my own 
question.  Correct me if I'm wrong:

* the redirect send the user to the above URL which is parsed in the main 
loop, which will cause the actions "sso_login" and "sso_login_succeeded" 
to be executed in sequence.

* do_sso_login is entered again. this time there is no POST so the rest of 
the code is executed: account created and attributes recorded.

* do_sso_login completes successfully with a return of 1 which sends it 
back to the main loop for the processing of the next action, ie. 
sso_login_succeeded.

* do_sso_login_succeeded does it's basic thing (don't quite get the 
distinction between nomenu and not nomenu) and then returns with 'home' so 
the next action becomes do_home, which loads the home page and will see 
the user logged in.

If this understanding is correct, I think I have enough understand to 
modify the sequence for my tests.

I basically intend to introduce an alternate flow through do_sso_login if 
the http_email_header is not to be trusted.  This will bring up a 
"remindpasswd" like screen (reworded to reflect that we just want to 
verify the address, though we technically know who the person is).  The 
submit button will then lead to a screen similar to the current login 
screen (email + passwd) which will serve to confirm the email address.  
After this I expect to do the tail end of do_sso_login where the account 
is created and attributes stored (but slightly modified to also store the 
users netid).

Do the above changes sound reasonable?  

~jpr

On Mon, 25 Apr 2005, Aumont - Comite Reseaux des Universites wrote:

> John-Paul Robinson wrote:
> 
> >Hi,
> >
> >I'm trying to add a few functions to the wwsympa.fcgi program. I've added
> >the function definition to the %comm hash and created the stubs in a
> >similar fashion to:
> >
> >sub do_sendssopasswd {
> >   do_log('info', 'do_sendssopasswd(%s)', $in{''});
> >   return 1;
> >}
> >
> >Are there any additional areas where a function must be defined?  
> >  
> >
> You may define its default argument in %action_args . Then they can be 
> extracted from the url and affected to parameters as defined in 
> "action_args" hash.  Do it even if your procedure is not supposed to 
> have argument (see exemple  'home').
> 
> >Also, could you provide me with a little insight into the construction and 
> >return of the URL to the client?  It looks like I should be able to set 
> >the $path and have that get returned to the client, but I'm not sure how 
> >this gets converted into the response.
> >  
> >
> I am note very sure of what you are looking for. I guess you want to 
> control what sympa will do after do_sendssopassword. An action 
> subroutine can finish with "return 1" or "return 'somenewaction' " so 
> wwsympa will continue with the new action requested. This is used in 
> subroutine do_login to exec the login request and return to the previous 
> action (the page wehe the authentication was requested). In can be used 
> also to redirect the user the page where is comming from if the variable 
> $in{'referer'} is initialized. Have a look at all "return" ending 
> do_login subroutine it will give you a clear idea of how it works.
> 
> Hope this help.
> Serge
> 
> 
>