[Building Sakai] Accessing HTTP Attributes in Sakai

[Steve Swinsburg]

Cool, post back if you get it it would be good info.

Cheers

sent from mobile
On 31/12/2013 2:14 AM, <markjnorton at earthlink.net> wrote:

> It's written and deployed as a JAR, deployed to shared/lib. I believe.
> I'll have a look at the RequestFacade class.  Thanks for the tips, Steve.
>
> - Mark
>
> -----Original Message-----
> From: Steve Swinsburg
> Sent: Dec 28, 2013 11:18 PM
> To: "Mark J. Norton"
> Cc: Charles Severance , dev sakai
> Subject: Re: [Building Sakai] Accessing HTTP Attributes in Sakai
>
>  Is it a web app (i.e. servlet based) or is it component code that you are
> writing? If web app, the RequestFilter strips a bunch of stuff out, you
> might be able to tell it not to strip certain attributes in the web.xml for
> the app you are writing, though that config might also only be specific
> attributes that the RequestFilter deals with that you can control.
>
> Since a sakai component is like a web app, I wonder if its possible to use
> the Tomcat RequestFacade class? That gives you the raw Request as a
> protected field, but you can make it visible.
>
> http://stackoverflow.com/questions/4997189/how-do-i-get-the-org-apache-catalina-connector-request-object-in-tomcat
>
>
>
>
> On Sat, Dec 28, 2013 at 9:16 AM, Mark J. Norton <markjnorton at earthlink.net
> > wrote:
>
>>  Chuck:
>>
>> The client (U. of Florida) tested the code I wrote based on your
>> suggestion.  I was really hoping it would work, but sadly - complete
>> failure.  I was after Shibboleth ID attributes, which should have been
>> present in the ServletRequest.  I can only assume that the portal null'ed
>> them all out.  Why does the portal do that, anyways?  There are legitimate
>> reasons for wanting access to that information, such as this one.
>>
>> Fortunately, UFL has a fall back position based on another approach I
>> wrote for them (using connection pooling).  That worked well, but they
>> still want a Shibboleth User Directory Provider.  Are you (or anyone else)
>> aware of a Shib UDP implementation?  Can you point me at the code?
>>
>> - Mark Norton
>>
>>
>> On 12/26/2013 10:08 PM, Charles Severance wrote:
>>
>> Mark,
>>
>>  I don't know if this helps, but I found myself stuck inside of Portlet
>> code unable to get a GET parameter in the Servlet request.  The Portlet API
>> works very hard to *not* give you access to the real underlyingServlet
>> request - but inside of Sakai, I made this work:
>>
>>
>> ./basiclti-portlet/src/java/org/sakaiproject/portlets/IMSBLTIPortlet.java
>>
>>  ...
>>  import javax.servlet.ServletRequest;
>> import org.sakaiproject.thread_local.cover.ThreadLocalManager;
>>  ...
>>      public final static String CURRENT_HTTP_REQUEST =
>> "org.sakaiproject.util.RequestFilter.http_request";
>>  ...
>>              // Grab that underlying request to get a GET parameter
>>             ServletRequest req = (ServletRequest)
>> ThreadLocalManager.get(CURRENT_HTTP_REQUEST);
>>             String popupDone = req.getParameter("sakai.popup");
>>
>>  Your mileage may vary - within Portlet UI View method so I knew exactly
>> where in the request lifecycle I would always be.  In library code It might
>> not be so clear where you are at in the request / response cycle...  One
>> call from a tool might work and a call from Quartz will blow up with an
>> NPE.   Caveat emptor.
>>
>>  Good luck.
>>
>>  /Chuck
>>
>>
>>  On Dec 26, 2013, at 9:08 AM, Mark J. Norton <markjnorton at earthlink.net>
>> wrote:
>>
>> Following up on this, can someone confirm that the Sakai ContextSession
>> object provides access to the current HTTP attributes?  Thedocumentation <https://source.sakaiproject.org/svn/kernel/trunk/api/src/main/java/org/sakaiproject/tool/api/ContextSession.java>is
>> a bit sparse.  ContextSession.getAttribute() has the comment:
>>
>>     Returns the object bound with the specified name in this session, or <code>null</code> if no object is bound under the name.
>>
>> I just need to be sure that the "session" here is the HTTP session,
>> rather than the Sakai session.
>>
>> - Mark
>>
>>
>>
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131231/8a196380/attachment.html