Alfresco Web Script Portlet rivet
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-15-2009 10:57 AM
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
- Labels:
-
Archive
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-26-2009 02:12 PM
I'm not sure if that will work in your case though so it would probably be best to use the next release of AWPr for this.
–Alaaeldin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-26-2009 02:24 PM
Sincerely thanks for help again, now I can't wait…in future I'll look for next release

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2009 12:01 PM
First I want to thank you for you awesome job with AWPr. It is very nice. Now about my situation, I'm experiencing some problems calling AWPRmyspaces webscript. I have mod_jk mounted and also I already configured the portlet in liferay so my enviroment taking account that apache is receiving all request is:
Apache: http://localhost
Alfreso: http://localhost/alfresco [http://localhost:8080/alfresco]
Liferay: http://localhost/* [http://localhost:8090/liferay]
I configured AWPrmyspaces webscript with the following:
alfrescoContextPath = /alfresco
alfrescoHost = http://localhost
httpMethod = GET
webscriptsParams = {f}[], {p}[], {alfUrl}[http://localhost/alfresco]
webScriptURL = /ui/awprmyspaces
Now the problems.
1.-Even though I can see the webscript, I am only able to visualize the default user space. When I give clic to the root or another folder in the path, I always go to the default path (like refreshing the webscript ). In other words the webscript is not taking into account the path of which folder I want to see. The thing is that when I call the webscript directly to tomcat (http://localhost:8080/wcservice/ui/awprmyspaces?alfUrl=http://localhost/alfresco ) from firefox it works fine, but from liferay it doesnt.The problem is basically that if I go directly to alfresco server it works, but If I dont and I call the webscript from liferay (awpr) and passing throughout the proxy it doesnt work, maybe it is a simple error but I havent worked with proxies until now. If you have any idea please tell me.
2.-Our alfresco repository contains some folders with latin chars like í, ó. So Awpr portlet its failing because it doesnt encode properly the folder name, I dont know why, but I checked the logs and it is sending the latin chars not being encoded as alfUrl param. However for example it is encoding spaces or other chars. Any idea what to do?
Thanks in advance for your help.
Diego
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2009 12:49 PM
What kind of error are you getting with the folder names? Can you please post the error in AWPr's jira?
http://issues.rivetlogic.com/browse/AWPR
Thanks,
–Alaaeldin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2009 05:27 AM
Thanks for you quick response. I already posted the error on AWPr´s Jira.
http://issues.rivetlogic.com/browse/AWPR-2
Thanks a lot ,
Diego
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2009 07:23 PM
I saw your solution about my problem but I'm not sure to understand. Please correct me If I misunderstood the cause. But according with your explanation, you will add an extra option to select the encoding type (UTF-8, ISO-8859-1) when sending the params in the portlet. But its supposed that UTF-8 is covering latin chars and many others right? I this is true why the portlet is required to use ISO-8859-1?
And about my first problem :
1.-Even though I can see the webscript, I am only able to visualize the default user space. When I give clic to the root or another folder in the path, I always go to the default path (like refreshing the webscript ). In other words the webscript is not taking into account the path of which folder I want to see. The thing is that when I call the webscript directly to tomcat (http://localhost:8080/wcservice/ui/awpr … t/alfresco ) from firefox it works fine, but from liferay it doesnt.The problem is basically that if I go directly to alfresco server it works, but If I dont, and I call the webscript from liferay (awpr) and passing throughout the proxy it doesnt work.
Do you have any clue to follow?
Thanks so much for your effort with this project,
Diego
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2009 07:34 PM
The character encoding restriction you will find is related to the database. By default (if I'm not mistaken) MySQL is set to use Latin-1 as the characterset:
mysql> status;————–mysql Ver 14.12 Distrib 5.0.51b, for apple-darwin9.0.0b5 (i686) using readline 5.0Connection id: 71Current database: Current user: root@localhostSSL: Not in useCurrent pager: stdoutUsing outfile: ''Using delimiter: ;Server version: 5.0.51b-log MySQL Community Server (GPL)Protocol version: 10Connection: Localhost via UNIX socketServer characterset: latin1Db characterset: latin1Client characterset: latin1Conn. characterset: latin1UNIX socket: /tmp/mysql.sockUptime: 4 days 22 hours 27 min 10 secThreads: 22 Questions: 203200 Slow queries: 0 Opens: 175 Flush tables: 1 Open tables: 169 Queries per second avg: 0.477
So what's happening here is that the webscript fails o find the path to the folder because the encoding is UTF-8. If your server configuration ensures the use of utf8 then things should work using UTF-8. I decided to make the character encoding a portlet preference to make AWPr more flexible.
Now regarding your other issue. It's related to the same character encoding problem. What's happening is that the way MySpaces and AWPrMySpaces are written is that if the folder you're trying to navigate to does not exist it will default to the user's home folder. Do your folders that have latin characters in them are failing and the webscript is sending you to the logged in user's Alfresco home folder.
Hope this helps.
–Alaaeldin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2009 07:36 PM
Another thing I noticed is that your Alfresco proxy setting should probably be fixed.
Currently it's set as follows:
http://localhost/alfresco [http://localhost:8080/alfresco]
You should set it like so:
http://localhost/alfresco* [http://localhost:8080/alfresco]
I have tested it with mod_jk, but if you want to use another proxy make sure you can access the Alfresco webclient using the following url:
http://localhost/alfresco
Cheers,
–Alaaeldin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-30-2009 10:49 PM
The main features are: (see the wiki for more details)
- Control over the AWPr javascript variable
- Control over which Web script URLs should be proxied
- Control over what type of encoding to use for request parameters
You can download AWPr 1.1.0 here.
Please use this forum if you have any questions about the new features.
Thanks,
–Alaaeldin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-01-2009 06:51 AM
I think I need to customize the Star amp (is it correct?) and so I'm looking for the source code of this amp, but I could not find them. Could you help me, please?
Thank you
Marco
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: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./alfresco/d/d/workspace/SpacesStore/771fbc61-d11a-4685-8a4d-143c310d07f0/image.png?ticket=TICKET_fb8dfe0f9fdf48b62e428fbe8f6665ddab01db55
–Alaaeldin
