[gradebook2-dev] gb.security.enabled setting questions

[Kevin Chan]

Hi all,

A curious thing happened while we started to do work for a Sakai 2.6 -> 
2.7 upgrade (and before we figured out what might have been causing the 
underlying issue)...

this header issue went away!

The only changes that I am aware of are:

JDK 1.5 upgraded to JDK 1.6
Sakai 2.6 upgraded to Sakai 2.7 (this includes a site-manage update from 
2.5 -> 2.7)

Not that I am complaining, but can anyone think of why this might have 
happened?

Also, anyone else running GB2 (v1.4.1) with Sakai 2.6 and JDK 1.5?

   Kevin Chan

   Operations Team
   Educational Technology Services
   UC Berkeley


On 2/24/11 2:54 PM, Kevin Chan wrote:
> Hi Jon,
>
> Thanks for the notes.
>
> Our setup (as is recommeded for Sakai) does include sticky sessions.
>
> I did look into the header issue and we may have something there:
>
> Error = X-XSRF-Cookie: No-Cookie
> OK = X-XSRF-Cookie: random-string-of-characters.hostname
>
> So I am taking a closer look there.
>
> Thanks,
>
>     Kevin Chan
>
>     Operations Team
>     Educational Technology Services
>     UC Berkeley
>
>
> On 2/23/11 2:44 PM, Jon Gorrono wrote:
>> The two main things the setting (to true) does are
>> 1. makes sure all requests go thru the portal and not thru the webapp
>> 'mount point'
>> and 2. makes sure the server thinks it has the same session that the
>> client says it thinks it has
>>
>> You'll get this error if the session manager returns a session id for
>> the current user that does not match (the first part of) the value in
>> the X-XSRF-Cookie header field, or of course, if that header is
>> missing.
>>
>> (or less commonly if a form submission does not have the right
>> sessionid in a certain hidden field)
>>
>> Is the load balancer passing on all header fields?
>> Are the sessions 'sticky' in that users are redirected to the same
>> host while in one session?
>>
>>
>>
>> On Wed, Feb 23, 2011 at 12:09 PM, Kevin Chan<kevin at media.berkeley.edu>   wrote:
>>> Hi again,
>>>
>>> Now that I have GB2 version 1.4 up and running, I am encountering some
>>> issues with the gb.security.enabled setting.
>>>
>>> Firstly, some info on our setup:
>>> * currently running 1.2.0; executed SQL update scripts for 1.2->1.3 upgrade;
>>> loading GB2 1.4.0
>>> * 3 DEV servers - 2 hosts (sakai-dev-01/sakai-dev-02) are being load
>>> balancer that distribute traffic going to "sakai-dev" to these 2 hosts
>>> evenly; optionally, you can go directly to these hosts by entering their
>>> respective hostnames; the third host (sakai-dev-03) is NOT behind load
>>> balancing
>>>
>>> It looks like our load balancing/Apache proxy setup is affecting this
>>> setting as going to the main hostname (sakai-dev) and the load balanced
>>> hostnames (-01 and -02) is causing an error.
>>>
>>> Here is the error from the front end:
>>> Security Exception
>>> Request Failed
>>> Unexpected response from server: 400
>>>
>>> and in catalina.out:
>>> 11:47:00,863 ERROR ServletWrappingController:160 - ERROR: X-XSRF-Cookie
>>> violation
>>> 11:47:00,864 ERROR ServletWrappingController:160 - ERROR: X-XSRF-Cookie
>>> violation
>>>
>>> Going to sakai-dev-03 = no problems.
>>> Changing gb2.security.enabled=false also fixes this error.
>>>
>>> So my two questions are:
>>> 1. What exactly does gb.security.enabled=true do?
>>> 2. Are there any settings (on the Sakai or GB2 code side) that I can change
>>> to make this work in our setup?
>>>
>>> Thanks,
>>>
>>> --
>>>     Kevin Chan
>>>
>>>     Operations Team
>>>     Educational Technology Services
>>>     UC Berkeley
>>>
>>> _______________________________________________
>>> gradebook2-dev mailing list
>>> gradebook2-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev
>>>
>>>
>>
> _______________________________________________
> gradebook2-dev mailing list
> gradebook2-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/gradebook2-dev