Alfresco Web Script Portlet rivet

[rivetlogic]

AWPr

AWPr is a JSR-168 portlet that can be used to expose remote Alfresco Web scripts, including those that need user authentication. With the help of a custom Alfresco authentication component that we wrote the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.

Motivation for AWPr

When integrating Alfresco Web scripts with JBoss Portal or Liferay Portal AWPr alleviates the need for having to deploy all of Alfresco inside the portal as is the case when using Alfresco's OOTB (out-of-the-box) Web script portlet for Alfresco/Portal integration.

AWPr is also highly configurable. Through the use of portlet preferences you can create multiple instances of AWPr and configure each one with a different Web script URL and a set of parameters with default values if needed. The instance will then RESTfully fetch the result of the Web script's render phase and carry that over to the portlet finally rendering it on the screen within the confines of the portlet window.

It is hence possible to run two instances of AWPr on a single portal page where each instance is exposing a different Web script even if those Web scripts are hosted on two different Alfresco servers regardless of their geographic location.

AWPr lives here:
http://wiki.rivetlogic.org/display/AWPr/

Feel free to ask questions about AWPr in this thread.

–Alaaeldin

[ahuja_neeraj]

Hi

I found AWPr is a very useful portlet. However while using this with the sample myspaces webscripts which interacts with alfresco I found that only the UI is rendered but but no content is displayed as shown in one of the screen shots.

After investigation I've found that there is a Javascript error in the connection-min.js files which halts the execution of the controller script. The error says

Access to restricted URI denied" code: "1012 while executing "o.conn.open(method,uri,true)" statement from connection-min.js files.

Please help me to resolve this error.

Regards
Neeraj

[rivetlogic]

Hi,

The reason this is happening is due to cross-domain security. You can resolve this issue using a proxy like mod_jk for example. The following wiki page explains what the proxy setup should do:

http://wiki.rivetlogic.com/display/AWPr/Example+Web+scripts

The basic idea is that Alfresco must be accessible using the same domain name as that of the portal.

Hope this helps,

–Alaaeldin

[marco_altieri]

Your portlet seems really interesting, but I would like to ask you a question.
If a portlet developed with "Rivet Web Script portlet" shows a link to a non public document inside Alfresco, can the user access it?
For example: MySpaces portlet can show the link below:
http://portal-hostname.com/alfresco/d/d/workspace/SpacesStore/1dacbd04-d028-482f-9359-a7e195f06442/f...
If the user clicks on it, the access to the document will not be a "liferay access", but a direct access to Alfresco, so the user wouldn't be authenticated. Would he?
How did you solve this problem? Should one use a standard SSO like CAS?

Thank you,
Marco

[rivetlogic]

Hi,

What's happening is that the MySpaces webscript adds a cookie with the Alfresco ticket in it to the client browser when the webscript is first rendered. Subsequent calls to the Alfresco download servlet will then be authenticated as the Liferay user.

The portlet will call the Alfresco login webscript initially to get an Alfresco ticket for the Liferay user. As a side note, this ticket is sent on every request from the AWPr portlet instance to Alfresco via a URL argument called 't'. This is to allow webscript authors to do whatever they want with that ticket.

If you copied the Alfresco download URL and pasted it into a browser that doesn't have the Alfresco cookie you will be redirected to the Alfresco login page. But if you add the parameter 'ticket=TICKET_<ticket-value>' you will be able to download the document if the user who owns the ticket has read rights on it.

The drawback here is that you wouldn't be able to robustly have more than one portlet on the same portal page displaying webscripts that serve download URLs from different unclustered Alfresco servers  because the cookie would keep getting overwritten. The only way would be to append the ticket to the download URL like so:

/alfresco/d/d/workspace/SpacesStore/771fbc61-d11a-4685-8a4d-143c310d07f0/image.png?ticket=TICKET_fb8dfe0f9fdf48b62e428fbe8f6665ddab01db55‍‍‍

This is ok but not desirable since accessing this URL from any browser will authenticate the request as that user which could pose a security risk.

–Alaaeldin

[nowhere]

Hi,
I found AWPr is an useful portlet to expose remote Alfresco Web scripts and fortunately I got it working. I also managed to expose entire alfresco under portal…but I didn't succeeded so I toke a chance with AWPr portlet.
Now, my problem is that I have already my webscripts, say webscript A and in A's ftl template I have a link to another webscript of mine, say B webscript…but I dind't find a way to open B on the screen within the confines of the portlet window. In the best case…it leave liferay portal and opens as simple alfresco webscritp (say url http://localhost:8080/wcservice/B.
Can anyone help me to solve this issue?
Greetings,
Rosa

[rivetlogic]

Hi,

AWPr provides a javascript function that can be used to convert Alfresco URLs to Liferay URLs in the client's browser. This function is used by awprmyspaces.js which is packaged with the example webscripts AMP.

The method is called AWPr.encodeUrl(). Of course this means that you won't be able to have more than one AWPr instance on the same portal page. The next AWPr release takes care of this issue by adding a portlet preference that allows you to configure the name of the javascript variable that holds the encodeUrl function thus allowing for multiple AWPr instances on the same portal page to have different javascript encodeUrl functions. The way it will work is as follows:

If the preference value is 'ABC', then the javascript variable will be called 'AWPr_ABC' and the function will be called like this:

AWPr_ABC.encodeUrl()

To see an example of how to use this function you can see this link: http://wiki.rivetlogic.com/display/AWPr/AWPr+Design#AWPrDesign-AJAXcalls

Another feature we will add is another portlet preference that allows you to configure what strings need to be replaced and what they should be replaced by. We could also have another portlet preference that allows you to configure other script URLs that need to be proxied. That way you could run webscripts that navigate back and forth between one another.

Hope this helps,

–Alaaeldin

[nowhere]

Hi Rivet,
thanks for your support… Now I'm facing with AJAX (JSON) calls made by myself…It's my first time with them so I'm getting what I want, but I can't say if it's correct.
I read about AWPr encodeUrl function, it seems interesting and I wrote a simple test but I didn't get what I need:

<script type="text/javascript"><!– function func() {   var link = document.getElementById("my");   link.setHTML('<a href="' + AWPr.encodeUrl("/alfresco/wcservice/quality/quality2") + '">Click Here</a>');}// –></script> <body onload="func();">   <div class="content">      <div id="articles">         <div id="right">                                                  <p id="my">temp</p>….(other stuff)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and what I get in href is "http://localhost:8081/web/guest/home?p_p_id=awpr_WAR_awpr_INSTANCE_Hm1D&p_p_lifecycle=1&p_p_state=no..." where I suppose istance is the same as first portlet load that is linked to webservce (/alfresco/wcservice/quality/quality1) (say A, as in my firts post), so I get a second call to same webscript and not to B (/alfresco/wcservice/quality/quality2). Surely I'm in wrong somewhere… Let me know what you think, also about making AJAX calls from zero. Sorry If I can't explain better , they all are new concepts to me.
Thanks again!

[rivetlogic]

Hi,

The current release of AWPr assumes that you are using a single webscript where all navigation happens within that webscript itself. The other supported scenario is for an outer webscript calling an inner webscript using an AJAX call much like what you see with MySpaces and MySpacesPanel.

We will try to support your use case by adding a portlet preference that accepts a list of script URLs that are to be proxied but I'm not sure when we will be able to release it. I'll update this forum when I have a date. I'll also try to include it in the upcoming 1.1.0 release.

How urgent is your need for this feature?

Thanks,

–Alaaeldin

[nowhere]

Hi again,
you are very kind…but I need it working in a few days, so don't considerate my needs in your release planning.

Still, I don't understand when you say:

The other supported scenario is for an outer webscript calling an inner webscript using an AJAX call much like what you see with MySpaces and MySpacesPanel.

Could you explain this?  ops: 
I can't understand if it fits my use case…May be I'm  misurdestanding, otherwise I'll continue working at my "silly" solution.