Help

JBoss CapeDwarf is an implementation of the Google App Engine API, which allows applications written for the Google AppEngine to be deployed on JBoss Application Servers without modification. Behind the scenes, CapeDwarf uses existing JBoss APIs such as Infinispan, JGroups, PicketLink, HornetQ and others.

The Users API

One of the smallest APIs of the Google AppEngine in terms of the number of API methods is the Users API. It basically contains only the following API methods: getLoginUrl, getCurrentUser and getLogoutUrl. By using the Users API, the application developer need not implement any kind of login system, because authentication is handled by AppEngine itself. Instead of directing the user to a custom login form, the application simply needs to point the user to the URL returned by getLoginUrl. This will allow the user to log in with either their Google account, their Google Apps Domain account or through an external OpenID provider. After the user logs in, they are redirected back to the application. The application can then obtain the logged-in user’s email address simply by calling the getCurrentUser API method.

In order to allow migration of existing GAE applications to and from CapeDwarf, CapeDwarf must also support using Google accounts and not introduce any custom method(s) of user authentication. Thanks to OpenID support in PicketLink Social this was pretty straightforward to achieve.

OpenID is an open standard that allows users to be authenticated by a trusted third party service. In CapeDwarf’s case, the third party service is the Google Accounts OpenID provider.

Using PicketLink Social to authenticate the user through Google Accounts is a very simple process.

Directing the user to the OpenID provider's authentication page

When the user requests the login URL returned by getLoginUrl, CapeDwarf’s AuthServlet instantiates an instance of PicketLink Social’s OpenIDManager, associates it with CapeDwarf’s own implementation of OpenIDProtocolAdapter and then simply instructs the OpenIDManager to authenticate the user:

OpenIDManager manager = new OpenIDManager(new OpenIDRequest("https://www.google.com/accounts/o8/id"));
CapedwarfOpenIDProtocolAdaptor adapter = new CapedwarfOpenIDProtocolAdaptor(request, response, getReturnUrl(request));
OpenIDManager.OpenIDProviderList providers = manager.discoverProviders();
OpenIDManager.OpenIDProviderInformation providerInfo = manager.associate(adapter, providers);
manager.authenticate(adapter, providerInfo);

Behind the scenes, the manager calls the OpenIDProtocolAdapter and instructs it to redirect the user to the OpenID provider’s URL. The redirect is achieved either through a standard HTTP redirect or by sending a self-submitting HTML form to the browser (this is necessary when the OpenID payload is larger than 2048 bytes).

The OpenID provider then displays the login form to the user (or authenticates the user in some other way).

Handling the user's return from the OpenID provider's authentication page

After the user is authenticated successfully, the provider redirects the browser back to the consumer - CapeDwarf. This returning request is also handled by AuthServlet. The servlet verifies if the user is authenticated by calling verify() on the OpenIDManager. If the user has been authenticated, CapeDwarf can now access the email address of the authenticated user, store it in the session and redirect the browser to the destination URL that was supplied by the application when it requested the login URL in the first step.

boolean authenticated = manager.verify(adapter, getStringToStringParameterMap(request), getFullRequestURL(request));
if (authenticated) {
    response.sendRedirect(request.getParameter(AuthServlet.DESTINATION_URL_PARAM));
}

During the invocation of the verify() method, the manager calls back our OpenIDProtocolAdapter with two types of OpenIDLifecycleEvents: SESSION and SUCCESS. The SESSION events instruct the adapter to store certain data in the session, while the SUCCESS event obviously signals that the authentication was successful.

The authentication process has now completed. Whenever the application now calls the User API’s getCurrentUser method, CapeDwarf will return the authenticated user’s email address. The email address simply identifies the user. It is up to the application to use this information whichever way it wants to.

How we handle application admins

On a final note, there is another API method that I haven’t mentioned yet: isUserAdmin. As is obvious from the method’s name, this method returns true if the logged in user is the admin of the application - either the Google user that uploaded the application to Google’s AppSpot or another user that was manually added as an admin by the application uploader through the Google Cloud Console.

Since there is no user account/email associated with deploying an AppEngine application to CapeDwarf, there is no notion of an admin. To specify who the app’s admins are, you need to list their email addresses in capedwarf-web.xml like this:

<capedwarf-web-app>
    <admin>my.email@gmail.com</admin>
    <admin>another.admin.email@gmail.com</admin>
</capedwarf-web-app>

Further info

For the complete source code of how CapeDwarf uses PicketLink Social, please turn to the Users module in CapeDwarf’s GitHub repo

3 comments:
 
20. May 2014, 10:37 CET | Link
Acceptance Kelly in addition to Primary <a href="http://chanelcoco.snappages.com/">fake chanel coco</a> Jacky Kennedy could typically make sure using Chanel.
ReplyQuote
 
09. Jun 2014, 11:41 CET | Link

Some will help make revenue at a zero cost or simply low-ball home business.

 
10. Jul 2014, 08:21 CET | Link

Fantastic vendors continue being abreast of the hottest general trends through trendy type not to mention take advantage of the chanel replica comparable bit data, along the lines of beading not to mention embellishments, that will make such fashion accessories take out from the public. Believe it or not, any time you had not purchased some copy back pack not too long ago, there's a chance you're flabbergasted by tag heuer replica in what way tight they've been in the originals. Chances are you isn't going to have the ability show typically the improvement. Good knockoff designer bags definitely will amaze most people aided by the better good. About the, he or she can have proper leatherette not to mention hard-wearing clothes which means exactly the same in the designer's attributes trend most people prada replica probably won't be able to share typically the improvement. The whole set of bit data could be furthermore there, much too, for instance the vibrant old watches level installing apart replica watches uk typically the zipper, typically the heavy-duty return back closure, and then the embossed leatherette creative logo. In just, they've been layered with the help of delightful, exceptional clothing. He or she can setback extraordinarily most certainly, explaining certainly no signs or symptoms from breakage straps, breaking leatherette and / or hermes replica tore upholster for which you sometimes check out with the help of less costly normally fabricated using.

Post Comment