Social Apps Proxy – Winning app in the Liferay Marketplace App Contest

MPAC-Winner-Badge-White-2Last month I entered and won this year’s Liferay Marketplace apps contest with my latest Liferay Portal app! There were some really good entries and it must have been a tough contest to call. Social Apps Proxy was my entry. It’s an app for drastically simplifying the building of other Liferay Portal apps that need to integrate with the social graph of its users. For example it can be used to retrieve recent mentions of the user on Twitter. That’s about 10 lines of code to achieve, and the full source code for this can be found here.

Social Apps proxy can be downloaded here.

Social Apps Proxy - Now available

Social Apps Proxy – Now available

James Falkner (Liferay community manager) wrote a good blog on the contest results.

In reality I started building the app some time before the contest was announced, because I wanted to combine my knowledge of a few different technologies that I had been working with in recent years. Namely XForms 1.1, OAuth 1.0a, and all things Liferay Portal!

The link to XForms 1.1 may seem obscure, but it was possibly my experience with XForms 1.1 that triggered the idea to build the app in the first place. XForms 1.1 has no native support for consuming OAuth services or parsing JSON data commonly returned by such services. It is however a superb framework for rapidly building complex forms using its model driven approach and excellent support for consuming HTTP services. So the idea was to create a HTTP proxy server which would do all the OAuth and JSON parsing (transforming it to XML) stuff on its behalf without it even being aware! Liferay Portal’s plug-able architecture provided a great opportunity to put a face on the proxy server for easy configuration and deployment. And from a user experience perspective, allowing users to managing their OAuth tokens for a whole website (web domain) hosted on Liferay Portal instead of using something specifically put together for an individual form (or portlet) is going to be more aligned with the user’s expectations of OAuth itself.

Integrating XForms with Liferay Portal is not something I will go into detail with, but Orbeon Forms is the XForms 1.1 implementation I am most familiar with and it comes with out of the box Liferay Portal integration. I’m sure other XForms implementations can also be integrated quite easily and Social Apps Proxy will work with those too!

So does that mean that Social Apps Proxy requires a XForms 1.1 implementation to be useful? Not at all. Any kind of app that can be deployed as a portlet to Liferay Portal can use Social Apps Proxy. Once installed, all portlets will automatically receive a special token as a render request attribute which indirectly links the app to all of the user’s OAuth tokens. Using the special token the app can request any OAuth resource as if it requires no OAuth token. Whenever this requires user authorisation the Social Apps Proxy will provide a special HTTP response with an authorisation URL which the portlet should simply send the user to.

So what’s next?

I’m going to be at a few upcoming Liferay conferences; The North America Symposium, London Solutions Forum, and the DevCon in Germany. It would be great to discuss how Social Apps Proxy could be improved so if you’re going to be at any of those events then great. Or you can simply leave a comment, it would be great to hear from you either way!



6 thoughts on “Social Apps Proxy – Winning app in the Liferay Marketplace App Contest

    • Stian- Touching base to see if you’ve had any success at the 6.2 version of your Social Apps Proxy. Happy New Year and best wishes to you! thank you- Marvin

      On Sun, Nov 30, 2014 at 5:36 PM, Metaphorm .blog wrote:

      > Stian Sigvartsen commented: “Hi Marvin. Yes I hope to release 6.2 CE & > EE versions over Christmas. It would be interesting to learn about what you > would like to achieve with Social Apps Proxy. Thanks for your interest! > Stian”

      • It’s not quite ready, but soon. I will push the latest code to Github as soon as it is tested. I am implementing a framework to further decouple the HTTP client implementation from the Social Apps Proxy core. There was a change in bundled HTTP client library between Liferay 6.1 and 6.2 which made this necessary to improve the maintainability of the 6.1 version upon the release of the 6.2 and future versions. This will also bring some additional benefits, which I’ll blog about soon.

        I noticed you asking on the Liferay forums about consuming 3rd party webservices using client side frameworks like JQuery. Will you be using Social Apps Proxy like this?

        Happy New Year!


      • Stian-
        yes, exactly. I’d like to be able to use the same (portlet) code on a pc and as an app on a mobile device. Unfortunately my technical depth is quite limited, hence this question: Does your Social Apps proxy play the same role as does Liferay’s OAuth Provider? If not, how are they different (functionally or technically)?
        thank you, and Happy New Year to you!

  1. Liferay’s OAuth Provider app is a bit like the equal opposite to Social Apps Proxy. It enables your Liferay Portal to be access by other apps/websites in the same way that you would say Twitter and Facebook. Such access can be via Social Apps Proxy, as it’s an OAuth consumer. So for example you could integrate two or more running Liferay Portals and provide a seamless user experience across them similar to having multiple sites on one Liferay Portal!

    Sounds like your mobile app will be HTML5 based rather than native if you intend to use the same portlet code. I suspect it will be tempting to include it in your portlet’s render response so it becomes available to JQuery on the client side. But it is important that the Social Apps Proxy secure token is transported securely, preferably out of sight from the client side. A solution which would provide better security is to store the secure token into the portlet session instead and provide JQuery with portlet API generated resource URLs in the render response.

    This approach is explained in more detail here:

    As an extension of this example, these resource URLs would be designed to retrieve the secure token from the portlet session and proxy requests onto the actual webservices you are interested in consuming, via Social Apps Proxy, and this code could be made generic to remove the need to tinker with it on a per webservice basis.

    I would be very happy to assist you in implementing this (open source it as an example on Github) so you can focus on your client side code.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s