cancel
Showing results for 
Search instead for 
Did you mean: 

DownloadContentServlet session timeout

sylvain78
Champ in-the-making
Champ in-the-making
Hi,

I am using the Web Services API to get a ticket without using the web-client login screen.

As configured in the authentication-context-service.xml file by default (Community Alfresco 2.1), the ticket should not expire.

But the DownloadContentServlet will timeout if the period of inactivity exceeds the alfresco session-timeout value in the web.xml.

I am talking about a request like the following:
/alfresco/download/attach/workspace/SpacesStore/0000-0000-0000-0000/myfile.pdf?ticket=1234567890
see (http://wiki.alfresco.com/wiki/URL_Addressability#Ticket_URL_Argument)

Is this the desirable behavior?

In my opinion, the ticket should not expire as long as I don't invoke the endSession method or tell alfresco to do so by configuring the authentication-context-service.xml file otherwise.

What do you think?

Thanks!
7 REPLIES 7

sylvain78
Champ in-the-making
Champ in-the-making
I still haven't found what is causing this, but it might have something to do with the ldap connector I am using.

I will post the solution to my problem when I find it.

maxmax
Champ in-the-making
Champ in-the-making
Hi guys,

I'm facing same issue with same conditions. When the ticket is "expired", i got some access denied errors, but no way to retrieve the file, that's why i'm
looking for the best way to solve this issue ?

I've got some ideas but i need your opinions :

The first quick fix would be enabling guestDownload and removing tickets … but for later use i can't retain this solution cause of audit needs.

The second way could be removing the ticket, then using the noderef instead of path url, which permit to log through the login page to access the file (using the downloadservlet with ticket doesnt allow me to do this; or maybe i made a mistake) and using sso in second time to avoid the login page

maxmax
Champ in-the-making
Champ in-the-making
solved using ntlm/sso

sisao
Champ in-the-making
Champ in-the-making
Hi,

can i have more information on how ntlm/sso would solve this issue? Will the LDAP work either?

maxmax
Champ in-the-making
Champ in-the-making
In fact, when you setup the filters authentication, you can force download components to use the authentication … so in the case the ticket is expired, your connection will pass trhrough ntlm auth

To do the trick, n  /opt/alfresco/tomcat/webapps/alfresco/WEB-INF/web.xml you can add/modify this :
(of course ntlm need to be properly enable & working before. From memories, this was no working with ldap auth. )


   <filter-mapping>
      <filter-name>Authentication Filter</filter-name>
      <url-pattern>/download/*</url-pattern>
   </filter-mapping>

   <filter-mapping>
      <filter-name>Authentication Filter</filter-name>
      <url-pattern>/d/d/*</url-pattern>
   </filter-mapping>

sisao
Champ in-the-making
Champ in-the-making
thx a lot

sisao
Champ in-the-making
Champ in-the-making
well even using the default auth system may work in my case, alfresco is acting as a repository for documents generated by a separate application, in which we map the documents and let the users download their stuff from alfresco directly.
They dont have users accounts in alfresco, but the application is the only one with a limited account, opening and destroying sessions via the WS API in order to upload and delete documents.
The problems occure with the downloads beacuse if the session is killed then any http request made to alfresco to /d/a/workspace/SpacesStore/uuid/filename will force the repository to ask the user for a login in order to download the file.
To avoid this i just refresh the session in the same time that particualr jsp is loaded (the one with the archive view…) without destroying it….it will rewrite the ticket everytime that page is refreshed.
I know this not the proper workaround but it lets us to keep on developing while having people not stop working on their workflow.

I'm quite curious to see how the repository will handle multiple requests made thorugh the same account via webservices API.