Saturday, June 14. 2014
Updating the old RDP portlet (Part II)
In a previous entry the updating process of the old RDP portlet was starting. The main new idea is using the FreeRDP project as the local program which launches the Remote Desktop / Terminal Services applications. This project presents all the features the portlet needs (RemoteApp for displaying the non-local applications seamlessly in the user's desktop, the gateway to use RDP over HTTPS and managing exported RDP files) but some of them are just supported in the beta version 1.1 and, in general, they need some love for polishing final details.
This second entry is dedicated to the portlet itself. The portlet was originally developed in the times that JSF 2.0 was being introduced and the technology was starting to be supported inside a portlet. Besides, instead of using a normal relational database, Cassandra NoSQL was used. Therefore the portlet used some curious technologies and projects which have been improved a lot since that time and, I think, some little summary is required.
The Cassandra project has been moved from version 0.6 to 2.0.7 and now everything is different. The old thrift client library (which was explained in detail in another entry of this blog) is now deprecated and a new CQL (Cassandra Query Language) client is recommended. This language is much more similar to standard SQL and working with it in java is easier for developers with experience in JDBC.
Another important piece of the portlet was the portletfaces-bridge, the library that made possible the use of JSF 2.0 inside a portlet. In the old entry this library was in alpha state but now it is part of the liferay community. Besides it is bundled with more libraries in a project called liferay faces. Therefore the bridge is now stable and the only feature which is quite new is CDI. The Context Injection was being introduced in the last versions of these libraries.
Finally the liferay portal is updated from 6.0.2 to 6.2 version. It is a less important change because a portlet is standardized enough to move smoothly from one version of liferay to another.
With all the information provided it is easy to understand that the portlet has been practically re-developed. The Cassandra manager (the class that interacts with the NoSQL database) changed from using the old thrift to the new CQL library. All the beans use the new CDI technology. And finally everything were updated to the new versions. There were also some changes because liferay (or the portlet bridge) does not support in-line images and constantly throws annoying errors with those types of links (the exception thrown was the same that is commented in this forum entry because the link of a in-line image has a uri of type data:image/png;base64,...). The solution is now using servlets for downloading icons and RDP files (I have re-used this fabulous file servlet coded by balusc). Here it is the link for the netbeans project for the tswebclient2 portlet.
And finally it is needed to change the script used to launch the FreeRDP command. In the past I did a horrible python script that parsed the RDP file and lauched the rdesktop application with the corresponding command line options. Now I have just created a little shell script that only requests the login information (domain, username and password) using zenity. Again it is very improbable and a real solution needs a better launcher. Here it is the freerdp-ask.sh script. Using firefox / iceweasel the script should be chosen to open RDP files (see the following image in which I configured iceweasel to always open those files with the script in the Edit → Preferences → Applications tab).
A video is presented below. A user accesses to the portal using iceweasel in a linux box. The portlet is displayed in the second tab of the portal. The mspaint application is clicked and immediately the script asks for the login information. Once the information is introduced the FreeRDP command is executed against the gateway server. As in the previous entry the nasty shifted cursor issue happens.
This is the last entry of a new series about Remote Desktop or Terminal Services. I tried to improve the previous solution, which was very limited in linux clients, with a new project called FreeRDP. Now the solution seems promising but it is still not ready for a real deployment. It is needed that the FreeRDP project supports RemoteApp feature and understands RDP files flawlessly. (It would be wonderful that the program would open a RDP file without the need of options, domain and username options should be used for gateway and host servers. A way of specifying the password somehow or, at least, requesting it graphically would be nice too).
Remote Regards!
Thursday, December 30. 2010
CalDAV and the Whitepages Portlet
In the past weeks the blog received some comments about the old caldav introduction series. If you remember this series consists of two entries, the first one introduces caldav and presents some http/webdav methods and the second post shows some real caldav requests. At that time I decided to not attach the complete project but linking every java file when it goes into stage. I thought this way would result in a better understanding but, obviously, I was wrong. For this reason I finally changed my mind and I am going to present the whole project and a real PoC example.
For some months I have been thinking in improving my little whitepages portlet (shown in both VoIP entries, Skype internet solution and Pidgin/OpenFire custom intranet project). It would be great if the whitepages, besides VoIP presence and interaction capabilities, could show the events or free/busy information for a specified company mate. This way any colleague can see what events has any other mate arranged for today and act accordingly.
It is quite clear that CalDAV is perfect for accessing the company calendar solution. In this case I have not installed any Calendar software (like I did with open sourced Calendar Server in the CalDAV entries) and the whitepages portlet will work against internet google and Yahoo! calendars. Finally I configured Yahoo! as the default calendar cos google does not support free-busy-query in its CalDAV implementation.
Before implementing the whitepages extension I worked with the old CalDAV project. Some jackrabbit libraries have been upgraded to new 2.2.0 version and another report has been implemented: free-busy-query. This report queries for the free/busy information of a user in a specified time. Its response only shows when the user has some events arranged, is busy, and when is free, but not specifying any detail of any event. If you check the libraries, jackrabbit-webdav depends on the old Commons HttpClient 3.1 which was superseded long time ago by a new HttpClient in the HttpComponents project (actual GA version 4.0.3). But its API has been deeply changed and jackrabbit needs some time to upgrade (see bug JCR-2406 for more details). This is an important issue to consider before choosing jackrabbit-webdav and I did not comment it before. As I promised here it is the complete CalDAV NetBeans project (libraries are missing because of space).
As I commented in previous VoIP entries the whitepages is a JSF 2.0 portlet application which uses OpenLDAP as the user repository. Every user entry has several attributes, and some of them are simply displayed (name, telephone,...) and others are treated specially. For example the jpegPhoto attribute is fetched and transformed into an image tag, the mail one is converted into a common email href link and skype/pidgin attribute is interpreted to show the presence and interaction links (start chat, add to my contacts,...).
For calendar integration a new attribute is used. This attribute is going to have the complete URI for the CalDAV Event collection of the user, in case of Yahoo! the attribute will be https://caldav.calendar.yahoo.com/dav/<yahoo-email>/Calendar/<calendar-name>/. But like the other special attributes, the calendar one will not be just presented, the URI will be used to access and query for the today user events. These events will be retrieved and presented to the end user. In order to fetch the events of a user calendar it must be shared with whitepages internal user or be totally public (i.e. any other google or Yahoo! user can see our events). In Yahoo! the calendar accessibility is set in Options → Share Calendar → Other Ways to Share → Public Link and in google in Settings → Calendar settings → Calendars → Click the calendar you want to share → Share this Calendar → Make this calendar public. In both sites there is an option to only share free/busy information and not make the calendar absolutely public (details are hidden and only availability is shown) but, also in both, this option does not work. Google does not support free-busy-query (CalDAV cannot access free/busy information) and in Yahoo! this option is disabled (with a beautiful coming soon message). In a custom calendar solution the whitepages could also be configured to use a superuser with special grants to access any other user calendar. But, as I commented, finally I set Yahoo! URI in the LDAP attribute of my entry and therefore my calendar must be public. The portlet tries first to obtain all the events arranged for today using calendar-query report (this needs all events to be public) and, if this first option does not work, it tries a second free-busy-query report to only show when the person is occupied (only free/busy access is needed).
Here it is a new video. My hypothetic boss wants to see the whitepages improvements before the department meeting at the afternoon and he searches for me in the intranet portal. After checking I have one hour free in the morning and I am online in Skype he decides to chat with me and arrange a meeting. I accept the offer and update my Yahoo! calendar. The update is immediately shown in the portlet.
I hope CalDAV entries were clearer now. This entry has attached the complete caldav project (see above for the link) and shows whitepages as a real example (very simple but a real one). I like the way my little whitepages application is being improved.
Happy new year!
Saturday, August 21. 2010
Integrating Terminal Services into a Portal (Linux Version)
Rdesktop is the traditional, and I think the only one, open source RDP solution. Until the time I faced that pre-sale I was not aware of the poor status of this project. Last rdesktop 1.6.0 version only supports version 5.2 of the remote desktop protocol and its releases are becoming more and more infrequent (1.6.0 was released in May 2008, 1.5.0 in September 2006, 1.4.1 in May 2005 and so on). The request to support RDP protocol 6.0 was open in the summer of 2007 (a year after 6.0 version was released with Windows Vista) and it is still not assigned. But, you know, this is open source, do not complain and do not wait others to do your job, fix it yourself! Now talking seriously, if somebody has enough time and skills and wants to participate in the never-ending war against Microsoft this is a good project that needs some love.
Coming back to the RDP portlet, Linux only has rdesktop and the portlet must work with it. The main restriction is that this program cannot use TS gateway, so only typical plain RDP (3389 TCP port) communication is possible (remember gateway can use the more secure, easier to integrate HTTPS protocol). This limitation makes absolutely compulsory the use of a VPN in order to establish a secure channel between an internet user and the server. And, of course, 5.2 protocol seems to be more bandwidth-hungry than 6.0/7.0 but nothing can be done with this issue.
Nevertheless seamless remote application was introduced in 1.5.0 rdesktop version. I am not really sure if this feature uses RDP 6.0 protocol or it was done ad hoc but, after all, rdesktop has the -A option to run a remote application. SeamlessRDP extension was a contribution of Cendio to rdesktop in another example of how open source works. This feature needs to install a server side windows program called seamlessrdpshell which is invoked by rdesktop as the alternate shell with the remote application to execute as an argument. For example:
$ rdesktop -A -s "seamlessrdpshell.exe c:\Windows\System32\mspaint.exe"In my windows 2008 server installation this program was installed under c:\Windows\System32\ directory (this way it is always found in the execution path). Besides the executable was published as a valid TS Remote Aplication with command line parameters enabled (TS Server lets it run with arguments).
Other issue is rdesktop does not understand rdp files (it is just a common linux command with several execution options). Some other graphical applications (like tsclient) can parse rdp files and call rdesktop accordingly but none of them (at least I could not find anyone) understands the seamless rdp integration (-A option). So I had to code a little python example that reads the rdp file and transforms the file tags into rdesktop options (plaease do not blame me, I already know there is room for improvement). The script needs two minor changes in the generated rdp file (now the alternate shell is specified with the full path to the application and the username is also supplied) but it still works for Microsoft client. Here it is a wordpad.rdp example. Finally the password to rdesktop invocation is hardcoded inside the script (I have commented the script is improvable, haven't I?).
With all the commented limitations the portlet solution is ready to be executed in linux. Now when the application link is clicked the downloaded rdp file will be executed by the python script, which will run rdesktop with the seamless application option. The video is very similar to the presented in the previous entry but with Debian as OS and firefox/iceweasel as browser. If you see when rdesktop is launched the usual windows login page is presented, automatically fulfilled, and then it disappears, the reason is rdesktop does not have Network Level Authentication (new feature of 6.1 version of the protocol).
In summary, this time linux solution is less practical (internet access needs a VPN, a better RDP file parser would be necessary in a real deployment and some bandwidth improvements are lost) but thinking in a global solition, I mean, a solution for all type of clients, is always a good thing and, this way, nobody will say I did not try it.
Keep the faith!
Comments