calling action in controller by direct action URL

[Ralf Haller, modificado hace 7 años.]

Hi,

is it possible to call an action in a faces controller by a direct action URL call with p_auth, so that www.test.com/page/-/portlet/action/save?p_auth=123 calls the method save in a faces controller class?

Ralf

[Neil Griffin, modificado hace 7 años.]

Are you using PrimeFaces? If so then you might be able to use p:remoteCommand to satisfy your requirement.

If not, then you can simulate clicking an h:commandButton (that is hidden from visibility in the DOM) if it has f:ajax as a child tag.

[Ralf Haller, modificado hace 7 años.]

Hi Neil,

what I need is a get URL...

Ralf

[Neil Griffin, modificado hace 7 años.]

When you wrote "get URL", do you mean a URL that you can call with XHR HTTP GET? If so, what type of content are you hoping to return?

[Ralf Haller, modificado hace 7 años.]

I'm trying to integrate a third party payment solution that sends a notification callback in the background (server to server) about the payment status. This callback needs to decrypt the parameters provided, check the signature and set the payment status of the order in the system accordingly.

Since the callback is made from a server and not the user the returned content does not matter.

[Neil Griffin, modificado hace 7 años.]

This type of server-to-server interaction is typically done by creating and invoking remote services rather than using a PortletURL to invoke a JSF action.

[Ralf Haller, modificado hace 7 años.]

Remote services use AXIS or JSON, the third party paymant solution I am trying to integrate however sends an HTTP Post with encrypted parameters.

[David H Nebinger, modificado hace 7 años.]

Ralf Haller:

Remote services use AXIS or JSON, the third party paymant solution I am trying to integrate however sends an HTTP Post with encrypted parameters.

Hey, Ralf, I actually wouldn't do this in a portlet request at all. Instead I'd just set up a regular servlet to handle the form submit, and protect the URL so it can only be invoked by whitelisted server addresses at the apache level.

You can use your Liferay SB code to call into the Liferay API to do whatever you need with the decrypted values, so there's no issue there.

And sticking with a servlet implementation, they likely can give you an example servlet that already does much of the heavy lifting, leaving you to deal with the actual storage.

And if your UI needs to wait on the response, your servlet can post the response on the Liferay Message Bus and your portlet can set up a listener to be notified of incoming messages and process them for UI responses.

[Ralf Haller, modificado hace 7 años.]

I think I need to give you guys more information about what I am trying to do.

I have a checkout portlet that asks the user for the address, delivery and payment mode. When the user selects PayPal the external payment solution redirects to PayPal. When the PayPal transaction is finished the browser will be redirected back to either successURL or failureURL which I gave initially when calling the external payment solution. These URLs may not have any parameters. In addition the payment solution calls a notificationURL directly from the server in the background just in case the redirect did not work.

When the failureURL is called the encrypted parameters have to be decrypted, the results need to be saved and an error message should be displayed to the user.

When the successURL is called the encrypted parameters have to be decrypted too, the results need to be saved and the checkout portlet shall display the summary page of the order.

The problems I have are the three calls from the payment solution. An action has to be taken (decrypt and store results), failure messages should be displayed in case of a failure, the summary view should be display in case of success (summary is not the default view of the checkout portlet).

The background notification shall trigger an action only with no view.

Any ideas how to achieve this?

Oh BTW, we are using Liferay CE 6.2.5...

[David H Nebinger, modificado hace 7 años.]

Okay, for the background notification I'd stick with my original suggestion of using a servlet to receive, decode and store the message.

For the active one, you're going to need to incorporate a friendly URL mapper. This is used to define a simple URL with some inferred parameters that allow the portal to map a simple URL to some sort of action in your portlet.

I'd probably try to use the same URL for both success and failure because I'm assuming there is distinguishing info in the encoded form params, and I also have to assume that the encoded params provide enough key details such that you can identify the cart transaction appropriately (otherwise you end up having to keep stuff in the session to persist state when one of these odd URLs are received).

During the request processing, since the incoming form parms are not namespaced, you may need to use PortalUtil.getHttpRequest(actionRequest) to get to the HttpServletRequest object and access the regular form parms. JSF gives you the FacesContext so you can get to the relevant request object, so you're good there.

So the incoming URL is handled by a friendly URL mapper to point to an action handler in your portlet, you can access the incoming form params, decrypt the values and do what you need to w/ the storage and/or render result.

Maybe not QED, but certainly possible.

[Ralf Haller, modificado hace 7 años.]

David H Nebinger:

So the incoming URL is handled by a friendly URL mapper to point to an action handler in your portlet, you can access the incoming form params, decrypt the values and do what you need to w/ the storage and/or render result.

That's exactly what I am looking for. How can this be done. We are using friendly urls already, but how to point to the action handler?

[Ralf Haller, modificado hace 7 años.]

So, how is it possible to create a friendly URL that directly calls a liferay faces action?

[Neil Griffin, modificado hace 7 años.]

Hi Ralf,

Liferay Faces Bridge supports the creation of a Liferay friendly-url with RenderURLs, ActionURLs, and RenderURLs.

If you are redirecting from the payment solution back to Liferay Portal, then you will probably want to use either a RenderURL via HTTP GET, or an ActionURL (via HTTP POST). ResourceURL is typically used for Ajax or perhaps for portlets with windowState="pop_up" or windowState="exclusive".

Invoking HTTP GET on a RenderURL is meant to be render a portal page in an idempotent way, meaning it doesn't change the state of the system. If your background action works, then the HTTP GET on the RenderURL is probably the way to go, since it will simply render the changed state of the system after the background action is processed.

Invoking HTTP POST on an ActionURL would also work, but it is designed to first change the state on the server, and then render the portal page. Sinc e the background action has already changed the state, it seems like HTTP POST on an ActionURL would be redundant.

You can use the portlet:renderURL Facelet tag in order to get String representations of your RenderURL. See the Liferay Faces Showcase for an example.

The Liferay Faces Showcase uses friendly-URL for each of the use-cases that are displayed. For more information, see liferay-portlet.xml and friendly-url-routes.xml.

Kind Regards,

Neil

[Neil Griffin, modificado hace 7 años.]

Moved to Liferay Portal - English - Development