[LON-CAPA-admin] cookie invalid

Fri Sep 20 13:46:09 EDT 2013

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 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>...
>>
>> 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=**
>>> 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
>>>
>>>
>> ______________________________**_________________
>> LON-CAPA-admin mailing list
>> LON-CAPA-admin at mail.lon-capa.**org <LON-CAPA-admin at mail.lon-capa.org>
>> http://mail.lon-capa.org/**mailman/listinfo/lon-capa-**admin<http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin>