My apologies! In my attempt to keep my message short I made it lacking
in context.
Yes what I am proposing is to add the functionality to allow WebAuth
admins to define new cookies to be included. More directly I'm asking if
this would be a feature that would be worthwhile for others.
The below patch are the changes we've made here at UVM for our specific
needs. It was meant to be illustrative of what I was describing more
than a proposed patch for the webauth source.
If others thought this had value I would work up a better patch,
including the suggestions Russ made.
Thanks for your time.
On 11/6/14, 13:40 , Russ Allbery wrote:
> Weighing in here randomly since I probably have the most context around
> this code at the moment.
>
> Greg Kuchyt <gkuc...@uvm.edu> writes:
>
>> It would be nice to be able to still set configurable cookies from
>> WebLogin variables in print_confirmation_page when BYPASS_CONFIRM is
>> set.
>
> I'm not entirely sure what change you're proposing in particular, since
> print_confirm_page doesn't have that functionality (setting configurable
> cookies from WebLogin variables) now. Maybe this is something you added
> locally? It only sends whatever $resp->cookies is set to at the start of
> the function, and it sends that for either the BYPASS_CONFIRM flow or the
> full page flow.
>
> Or maybe I'm reading it wrong? It's been a while.
>
>> --- a/usr/local/lib64/perl5/WebLogin.pm
>> +++ b/usr/local/lib64/perl5/WebLogin.pm
>> @@ -415,6 +415,12 @@ sub print_headers {
>> -value => $value,
>> -secure => $secure,
>> -httponly => 1);
>> +
>> + # Per WAS cookie to track for single logout capabilities
>> + } elsif ($name =~ /^wa_logout/) {
>> + $cookie = $q->cookie (-name => $name,
>> + -value => $value,
>> + -secure => $secure);
>> }
>
> Currently, print_headers is doing all the filtering of the $resp->cookies
> cookies to decide which ones to send. It would probably make sense to
> move that to a separate function to clean up the division of labor between
> these functions, but that's a larger change.
>
> Rather than adding more special cases to that filtering to handle new
> cookies that you're adding, it probably would make more sense to add a new
> parameter to print_headers that lists the extra cookies that you want to
> send, apart from print_headers's current logic. Then, any other changes
> you make that want to set cookies can just pass in the additional cookies
> in that separate parameter and not have to modify print_headers to pass
> them through.
>
