Shib with REST and AJAX Best Practices

[Russell J Yount]

>>2) Add the following directives to the httpd.conf file (they added them 
>>globally, but there is no reason it couldn't be done at a directory 
>>level I suppose):

>I don't understand what that has to do with AJAX either. Anything the browser is accessing obviously needs appropriate cache policy. If it's dynamic content, then obviously it should be marked as such.

Scott, Let me explain. 

The browser references an html page which contains javascript modules and a command to start a javascript operation to paint users browser screen.

The first time the html page is referenced, shibboleth intercepts the GET of the html page and authenticates, then javascript modules are download and started.

Assuming some time passes, maybe users does some things and shibboleth authentication expires.

Case 1: In next reference to the html page the user is going to page and the browser does not do a GET of the html page because it is cached, the javascript modules however are always downloaded and Shibboleth intercepts the download and sends a 302 which the javascript does not understand. 

Case 2: A user is at the html page, javascript has already painted screen, user clicks sending an event to javascript which send a REST request to Apache/Ruby, Shibboleth intercepts the REST request and sends a 302 which the javascript does not understand.

If the html page is set to not cache in both cases references to the html page cause browser to do a GET and shibboleth authentication occurs before the javascript download in case 1, or REST request is sent in case 2.

-Russ


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, September 13, 2011 9:56 AM
To: users at shibboleth.net
Subject: Re: Shib with REST and AJAX Best Practices

On 9/13/11 8:16 AM, "Russell J Yount" <rjy at cmu.edu> wrote:
>The groups solution has been to:
> 
>1) Change the sessions statement to look something like this:
> 
><Sessions lifetime="28800" timeout="86400" checkAddress="false"
>relayState="ss:mem" handlerSSL="true">
> 
>The key here is setting the lifetime value lower than the timeout value.

The session will still expire eventually, so I don't understand the value
of that.

>2) Add the following directives to the httpd.conf file (they added them
>globally, but there is no reason it couldn't be done at a directory level
>I suppose):

I don't understand what that has to do with AJAX either. Anything the
browser is accessing obviously needs appropriate cache policy. If it's
dynamic content, then obviously it should be marked as such.

> 
>This seems to work for them. Is there a better way to handle this?

I don't think either has anything to do with the problem.

> 
>One possible alternative I have suggested would be to have the
>application manage its own session (using on authentication page
>protected by Shibboleth).

If you want the application to manage the session, you can just use lazy
sessions with the SP also. Same effect.

> 
>What is the best practice for this?

Fix HTTP? There's no way to use AJAX in conjunction with security
mechanisms that the client doesn't know anything about. At the end of the
day, it's a broken model.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net