[Building Sakai] Accessing HTTP Attributes in Sakai

[Steve Swinsburg]

 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/20131229/aca26bc6/attachment.html