Synchronize Authentication

[johnwarthman]

I am trying to build a windows-based application to help my company use Share.  In one panel, I use a WebBrowser control to allow access directly (this seems to be working in general), and in another panel, I am making more direct access to certain file activities (my users do not like the Share Document Library interface).  I am using the calls to WebScripts (using v3.1) to acheive this.

I have run into the problem that I cannot synchronize the Share login with the webscripts login.  If I log in via webscript, I cannot overrride the share login with the alf_Ticket as the wiki suggests. 

If I log into Share through the browser, I cannot access the session information in a useful way to gather the credentials to synchronize them.  There may be a trick to this part that I do not know - I am new to both Share and the WebBrowser control.

Any suggestions or resource links would be welcome.

Thank you!

PS, as a small note to the side, the returned ticket in JSON doesn't have the quotation marks around each item.  I am new to JSON, but the JSON.Net parser I used choked and said it was out of spec.  It is the only script I've seen have this problem so far.   It was easily worked around, so please don't reply to the issue here.

[mikeh]

Although I haven't tried it, in order to re-use the Share session you'd have to grab the session details from the WebBrowser control. These should all be in cookies: look for alfLogin, alfUsername2 and the JSESSIONID. Then make all your webscript calls via Share's /proxy servlet rather than to the repository directly. You could probably get the login ticket via that route and then bypass the proxy servlet if you so wished - again, not tried.

Out of interest, what is it about the Document Library that your users don't like? We're always looking for user feedback, both positive and negative, in order to direct future development.

Also, which webscript returned invalid JSON? I had a quick look but couldn't find an offending one.

Thanks,
Mike

[johnwarthman]

These should all be in cookies: look for alfLogin, alfUsername2 and the JSESSIONID. Then make all your webscript calls via Share's /proxy servlet rather than to the repository directly.

I do not see alfUsername2 in the cookies.  Here is what I see:
alfLogin=1248905973; JSESSIONID=870D8DF6EFCDF5BB8C81AF406C222E9C

I am not familiar with the proxy servlet, having only come across a few references to it in forums.  I will look into it further for my needs.  This seems a reasonable strategy for the moment.

Out of interest, what is it about the Document Library that your users don't like? We're always looking for user feedback, both positive and negative, in order to direct future development.

In increasing priority…
1. Icons – Share shows previews where possible and a placeholder where otherwise.  Many of our files are similar, and the previews make them appear almost uniform even across types (a preview of the first page of a powerpoint file, the PDF made from it, and the XLS file with the same cover page all blend together). 
2. The Share methods for download and/or checking out files is cumbersome and confusing.  Some files, for some people, have "Edit Offline" and "Download" for options.  Both must save a local copy which is opened to edit.  Only Edit Offline actually checks out the file.  Some people get the "Edit Online" option for some files, which does check them out and does not save a local copy, but are terribly slow to use.  Aside from the assumption "Edit Online" would be with Office files, the option's presence is intermittent (people with the same versions of Office don't get the option).  All of the variations are confusing people and making it difficult to write simple procedures for the company.  Furthermore, since getting away from local files was one of the goals, people are seeing it as counterproductive (even if I understand it is actually progress!).
3. The Share methods of checking files back in is more annoying to my users than checking out.  IF someone downloads rather than edits offline, they have to go back, select edit offline, save the file somewhere, check their original file in and then delete both local copies.  Even if they did it right, they still have the check-in process and the local copy to delete.  Even via edits online, they have to save it and do some sort of check-in step to make it work right (and it's still slow). 

As a programmer I can see why you implemented these steps, but I am constantly asked "Why can't I just open it, and then save it when I'm done?".  My goal is to write an app native to windows (picks up icons) that automatically do the local copies and check-in/out behind the scenes, and still presents the rest of Share for all the great stuff in it.

Also, which webscript returned invalid JSON? I had a quick look but couldn't find an offending one.

POST alfresco/service/api/login

According to specs, I send the username and password in JSON format, and I get back the ticket in JSON format.  Here is a response (the same for wcservice if it matters):
{
   data:
   {
   ticket:TICKET_5b467e06f40c8146ca71214475ebf091147da542
   }
}

Again, this could be fine.  The JSON parser I used demanded the ticket have quotation marks (e.g. "ticket":"TICKET_5b467e06f40c8146ca71214475ebf091147da542").  I just wrote a simple parser to get the ticket and bypassed my main parser for that one operation.

Thank you for you help and quick response.

[mikeh]

I do not see alfUsername2 in the cookies.  Here is what I see:
alfLogin=1248905973; JSESSIONID=870D8DF6EFCDF5BB8C81AF406C222E9C

Ah, sorry that's probably a development value - I believe you do only need those two.

I am not familiar with the proxy servlet, having only come across a few references to it in forums.  I will look into it further for my needs.  This seems a reasonable strategy for the moment.

If you examine the communication between Share and the Repository, webscripts are proxied through the /proxy servlet, which handles authentication. It uses a set of declared endpoints, e.g. "alfresco", "alfresco-feed", etc. Most Share AJAX scripts are directed through proxy/alfresco which maps to the /service servlet (aliased to "/s") on the Repository tier.

1. Icons – Share shows previews where possible and a placeholder where otherwise.  Many of our files are similar, and the previews make them appear almost uniform even across types (a preview of the first page of a powerpoint file, the PDF made from it, and the XLS file with the same cover page all blend together).

That's an interesting point - especially .ppts which often have a "company cover page". Having a quick look inside org.alfresco.repo.content.transform.PdfToImageContentTransformer, it looks like we only ever grab the first page. We should probably make that configurable. In the meantime, you could get it to generate from page 2 by changing that class (check there are two pages via pdffile.getNumPages() )

2. The Share methods for download and/or checking out files is cumbersome and confusing.  Some files, for some people, have "Edit Offline" and "Download" for options.  Both must save a local copy which is opened to edit.  Only Edit Offline actually checks out the file.  Some people get the "Edit Online" option for some files, which does check them out and does not save a local copy, but are terribly slow to use.  Aside from the assumption "Edit Online" would be with Office files, the option's presence is intermittent (people with the same versions of Office don't get the option).  All of the variations are confusing people and making it difficult to write simple procedures for the company.  Furthermore, since getting away from local files was one of the goals, people are seeing it as counterproductive (even if I understand it is actually progress!).

Something we'd definitely like to improve, possibly using an Adobe AIR app or similar. The problem is Share is still a web site, with all the limitations that brings. The reason some of your users are seeing Edit Online is that they're using MSIE and looking at an MS Office file that supports WebDAV editing. Also, I'm guessing you've installed the Sharepoint Vti module on the server? The IE/Office combination is the only way to get "online editing", even then you need a couple of support patches. See http://forums.alfresco.com/en/viewtopic.php?f=9&t=18880

3. The Share methods of checking files back in is more annoying to my users than checking out.  IF someone downloads rather than edits offline, they have to go back, select edit offline, save the file somewhere, check their original file in and then delete both local copies.  Even if they did it right, they still have the check-in process and the local copy to delete.  Even via edits online, they have to save it and do some sort of check-in step to make it work right (and it's still slow). 

As a programmer I can see why you implemented these steps, but I am constantly asked "Why can't I just open it, and then save it when I'm done?".  My goal is to write an app native to windows (picks up icons) that automatically do the local copies and check-in/out behind the scenes, and still presents the rest of Share for all the great stuff in it.

If I recall, v3.1 doesn't have the "Upload New Version" action on the main DocLib browse view? It sounds like that's what your users would prefer to use. It's available in v3.2 or you can patch it into v3.1 by editing the actions section of documentlist.get.html.ftl (something else which is much easier in v3.2)

POST alfresco/service/api/login

Thanks - that's fixed in v3.2.

Cheers,
Mike