[LON-CAPA-admin] cookie invalid

[Stuart Raeburn]

Hi,

> Is it possible to have the lonbalancer hosts the session if different IP
> address is detected? The reason is so that I don't have add another server
> with SSO.

Yes. That sounds like a reasonable option.

I have included that as an additional option for incorporation in the  
changes to address bug 6675; see --  
http://bugs.loncapa.org/show_bug.cgi?id=6675

Stuart Raeburn
LON-CAPA Academic Consortium


Quoting hkng <hkng at fsu.edu>:

> Hi,
>
> Is it possible to have the lonbalancer hosts the session if different IP
> address is detected? The reason is so that I don't have add another server
> with SSO.
>
> Thanks,
> -hk
>
>
> On Friday, September 20, 2013, Stuart Raeburn wrote:
>
>> Hi hk,
>>
>>  Is it "safe" to remove $data{'ip'} ne $ENV{'REMOTE_ADDR'} temporarily
>>> until
>>> a solution can be found?
>>>
>>
>> Personally, I would not do that.
>>
>> The IP check has been a part of /adm/migrateuser since rev 1.1.  However,
>> the current process needs improvement.
>>
>> As regards your specific situation where users are accessing LON-CAPA via
>> a cellular network, my preference would be to require re-authentication,
>> but have that occur on the server selected to host the session in order to
>> avoid a repeat of the use of /adm/switchserver and then /adm/migrateuser
>> (in which their could be yet another client IP change).
>>
>> Depending on how SSO is configured, a SSO-authenticated user might not
>> need to re-authenticate, if you are able to verify the user's SSO
>> credentials on your regular access servers, as well as on your lonbalancer
>> server.  It looks as though you currently use CAS single sign on for both
>> loncapa.fsu.edu and loncapa10.fsu.edu.
>>
>> Anyway I have assigned myself a bug for this --
>> http://bugs.loncapa.org/show_**bug.cgi?id=6675<http://bugs.loncapa.org/show_bug.cgi?id=6675>and will work on it   
>> today.
>>
>>
>> Stuart
>>
>> Stuart Raeburn
>> LON-CAPA Academic Consortium
>>
>>
>> Quoting hkng <hkng at fsu.edu>:
>>
>>  Thanks Stuart,
>>>
>>> Is it "safe" to remove $data{'ip'} ne $ENV{'REMOTE_ADDR'} temporarily
>>> until
>>> a solution can be found? In the past, this problem occurs infrequently but
>>> now I see it very often each day.
>>>
>>> Regards,
>>> -hk
>>>
>>>
>>>
>>> H. K. Ng
>>> Associate Professor of Physics
>>> Department of Physics
>>> Florida State University
>>> Tallahassee, FL 32306-4350
>>>
>>>
>>> On Thu, Sep 19, 2013 at 5:42 PM, Stuart Raeburn <raeburn at msu.edu> wrote:
>>>
>>>  Hi,
>>>>
>>>>
>>>>  Some how when the session is transferred from the lonbalancer to the
>>>>
>>>>> access
>>>>> server, a different ip address is reported to the access server. This is
>>>>> the only clue I can find as to why the student cannot get to the roles
>>>>> page. Maybe it is a red herring. So question is has anyone seen this
>>>>> behavior before? Also, why is the ip address different?
>>>>>
>>>>>
>>>> Looking at the lonbalancer code in LON-CAPA 2.10.1, I see that
>>>> $ENV{'REMOTE_ADDR'}, as reported by the client browser, needs to be
>>>> consistent across two stages in the LON-CAPA log-in process involving a
>>>> lonbalancer.
>>>>
>>>> $ENV{'REMOTE_ADDR'} is retrieved from the client request as follows:
>>>>
>>>> (a) from the submission of log-in information to /adm/login on the
>>>> lonbalancer
>>>> (b) from the page reload included in the response from the
>>>> /adm/switchserver browser's refresh within the meta tag:
>>>> <meta http-equiv="Refresh" content="0.5";  url=http://
>>>> <otherserver>/adm/****login"
>>>> />
>>>>
>>>> where <otherserver> is the hostname of the LON-CAPA server which will
>>>> host
>>>> the user's session after transfer from the lonbalancer server.
>>>>
>>>> See lines 81-84 of  /home/httpd/lib/perl/Apache/**mi**grateuser.pm<
>>>> http://**migrateuser.pm <http://migrateuser.pm>>...
>>>>
>>>> if ($data{'ip'} ne $ENV{'REMOTE_ADDR'} || !defined($data{'username'}) ||
>>>>     !defined($data{'domain'}) ) {
>>>>     return &goto_login($r);
>>>> }
>>>>
>>>> $data{'ip'} is retrieved (by migrateuser.pm on the target server) from
>>>> the frozen hash stored in /home/httpd/perl/tmp (identified by token).
>>>>  The
>>>> frozen hash on the target server will have originally been stored by
>>>> /home/httpd/lib/perl/Apache/**sw**itchserver.pm  <http://switchserver.pm
>>>> >**running on the lonbalancer server.
>>>>
>>>> In the case of connections through a cellular network, the comparison
>>>> between $data{'ip'} and $ENV{'REMOTE_ADDR'} could fail if the service
>>>> provider is using multiple gateways with multiple IP addresses, and the
>>>> particular gateway used for a student's wireless connection changes
>>>> between
>>>> a client browser's calls to /adm/login and /adm/migrateuser.
>>>>
>>>>
>>>>
>>>> Stuart Raeburn
>>>> LON-CAPA Academic Consortium
>>>>
>>>> Quoting hkng <hkng at fsu.edu>:
>>>>
>>>>  Hi,
>>>>
>>>>>
>>>>> I posted this question before but never got any response. When student
>>>>> login using a portable device (like iPad) and using the cellular network
>>>>> to
>>>>> the lonbalancer, the student is be authenticated and is then transferred
>>>>> to
>>>>> one of the access server. However, the session immediately got kick back
>>>>> to
>>>>> the lonbalancer, and because the system uses SSO, it immediately
>>>>> transfers
>>>>> the session back to the access server. It forms an endless loop and the
>>>>> student never get to the roles page.
>>>>>
>>>>> Checking the logs this is what I can determine.
>>>>>
>>>>> In the activities log, there are lots of sequential entries like
>>>>>
>>>>> 1379531706:fsua0:Switch Server to fsua2 with role <ip address> almost
>>>>> always coming from mobile-xxx-mycingular.net
>>>>>
>>>>> Checking the lonbalancer log (under /var/log/httpd) there are entries
>>>>> like
>>>>>
>>>>> ssl_access_log:ip address - - [18/Sep/2013:15:23:31 -0400] "GET
>>>>> /adm/roles?ticket=ST-1954238-****wIoLGFGIQacDNCdcsrXy-casprd2
>>>>> HTTP/1.1" 200
>>>>> 11318
>>>>>
>>>>> ssl_error_log:[Wed Sep 18 15:10:33 2013] [error] access to
>>>>> /home/httpd/html/adm/****switchserver failed for <ip address>, reason:
>>>>> Cookie
>>>>> not valid
>>>>>
>>>>> In the access server log, there is no entries with the ip address but
>>>>> there
>>>>> are entries with the username like
>>>>>
>>>>> access_log:<different ip address from lonbalancer> - -
>>>>> [18/Sep/2013:15:10:32 -0400] "GET /adm/login HTTP/1.1" 200 2795 "
>>>>> http://loncapa2.fsu.edu/adm/****login?domain=fsu&username=**<http://loncapa2.fsu.edu/adm/**login?domain=fsu&username=**>
>>>>> xxxxx&token=24824_128_186_7_****151_9<http://loncapa2.fsu.edu/**
>>>>> adm/login?domain=fsu&username=**xxxxx&token=24824_128_186_7_**151_9<http://loncapa2.fsu.edu/adm/login?domain=fsu&username=xxxxx&token=24824_128_186_7_151_9>
>>>>> >
>>>>> "
>>>>> "Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_3 like Mac OS X)
>>>>> AppleWebKit/536.26
>>>>> (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25"
>>>>>
>>>>> Some how when the session is transferred from the lonbalancer to the
>>>>> access
>>>>> server, a different ip address is reported to the access server. This is
>>>>> the only clue I can find as to why the student cannot get to the roles
>>>>> page. Maybe it is a red herring. So question is has anyone seen this
>>>>> behavior before? Also, why is the ip address different?
>>>>>
>>>>> Any pointers?
>>>>>
>>>>> Thanks,
>>>>> -hk