[14:30:12 CDT(-0500)] <EricDalquist> drewwills: there?
[14:45:14 CDT(-0500)] <cwaymire> EricDalquist: hey got a quick question for you.
[14:45:19 CDT(-0500)] <EricDalquist> ok
[14:46:35 CDT(-0500)] <cwaymire> i've got a portlet that I added a Spring MVC controller into. I noticed that when calls come into that controller they have neither an active HttpSession nor does the request object contain a remote username.
[14:46:49 CDT(-0500)] <EricDalquist> this is a servlet controller?
[14:46:53 CDT(-0500)] <cwaymire> in this instance its important that I be able to get the user name
[14:46:59 CDT(-0500)] <cwaymire> yeah. standard spring mvc controller
[14:47:17 CDT(-0500)] <EricDalquist> so for the session to exist you need to make sure that the tomcat instance has emptySessionPath set to true
[14:47:24 CDT(-0500)] <EricDalquist> or whatever the TC7 version of that is
[14:47:31 CDT(-0500)] <EricDalquist> there will never be a remoteUser though
[14:47:33 CDT(-0500)] <cwaymire> let me double check my setting
[14:47:43 CDT(-0500)] <EricDalquist> that servlet is being directly accessed by the client
[14:47:49 CDT(-0500)] <EricDalquist> the portal has zero control over it
[14:48:00 CDT(-0500)] <EricDalquist> so none of the portal user's "state" is available
[14:48:07 CDT(-0500)] <EricDalquist> and in fact the session will only exist
[14:48:16 CDT(-0500)] <EricDalquist> if you have previously accessed a portlet in the same webapp
[14:48:19 CDT(-0500)] <EricDalquist> and that portlet created a session
[14:48:43 CDT(-0500)] <cwaymire> which is the case. are there any tricks to getting the username of the authenticated user?
[14:49:39 CDT(-0500)] <EricDalquist> the only way
[14:49:48 CDT(-0500)] <EricDalquist> is for the user to visit the portlet first
[14:49:57 CDT(-0500)] <EricDalquist> the portlet stores the username in the application scope in the portlet session
[14:50:01 CDT(-0500)] <EricDalquist> then the servlet can see that value
[14:50:10 CDT(-0500)] <EricDalquist> if the servlet is the first point of contact though
[14:50:10 CDT(-0500)] <EricDalquist> no
[14:50:12 CDT(-0500)] <EricDalquist> there is no way
[14:51:14 CDT(-0500)] <cwaymire> The portlet (Attachments) will always be there. It will basically be a hidden div on the page. An interaction in another portlet will cause a lightbox to display allowing the user to select a file to upload via a multipart POST.
[14:51:51 CDT(-0500)] <cwaymire> but I need to know who the user was that submitted the upload.
[14:52:13 CDT(-0500)] <EricDalquist> yeah they would need to visit the portlet first
[14:52:17 CDT(-0500)] <EricDalquist> why not have them upload to the porlet
[14:52:26 CDT(-0500)] <EricDalquist> portlets can deal with uploads via action and resource urls
[14:53:49 CDT(-0500)] <cwaymire> the idea was that the Attachments portlet would basically be an invisible portlet that wasnt rendered but would expose a global javascript api that would open up a lightbox div on the page allowing you to upload a file. So any portlet that wants to use attachments can simply call the global js method and give it a callback method. When the upload is done the callback method is executed with some result data.
[14:54:28 CDT(-0500)] <EricDalquist> so you are 'uploading" to the javascript?
[14:54:55 CDT(-0500)] <EricDalquist> or is the attachment stored somewhere that other portlets could potentially reference/access?
[14:55:51 CDT(-0500)] <cwaymire> the javascript makes an ajax call to submit the file to the controller which creates some database rows and will store the file on the filesystem.