I have a java webapp using the Tapestry5 framework where I'm seeing exceptions in my logs that look something like this,
Forms require that the request method be POST and that the t:formdata
query parameter have values
When I spoke to the user group, it was believed that there is some sort of issue where the browser is turning a form post into a get request. I've been seeing this happen with legacy versions of ie and modern android devices using later versions of chrome.
My question is what would cause this type of behavior?
Edit:
Example form
<form id="sortForm" method="post" action="/product/index.sortform" data-validate="submit">
I'd also like to rule out bot activity do to the fact I see this happening on some of my apps that sit behind firewalls without any bot access.
The problem caused by address bar completion of all browsers and the solution is that, please add autocomplete="false" to all of your forms.
Edit 1:
If you do not use action type, it works like "GET" method. Be sure that you added the action "method" attribute value of the form as "POST".
Edit 2:
Please check GET submits instead of POST ones. Tapestry
There was a major error emphasized at that link (jira) https://issues.apache.org/jira/browse/TAP5-2066 which is solved before.
Related
I am currently learning JSF and was rather amazed and puzzled when I realized that whenever we use <h:form>, the standard behavior of JSF is to always show me the URL of the previous page in the browser, as opposed to the URL of the current page.
I understand that this has to do with the way JSF always posts a form to the same page and then just renders whatever page the controller gives it back to the browser which doesn't know the page location has changed.
It seems like JSF has been around for long enough that there must be a clean, solid way to deal with this. If so, would you mind sharing?
I have found various workarounds, but sadly nothing that seems like a real solid solution.
Simply accept that the URL is misleading.
Append "?faces-redirect=true" to the return value of every bean's action and then
figure out how to replace #RequestScoped with something else (Flash Scopes, CDI conversation, #SessionScoped, ...).
accept to have two HTTP round trips for every user action.
Use some method (e.g. 3rd party library or custom code) to hide the page name in the URL, always using the same generic URL for every page.
If "?faces-redirect=true" is as good as it gets, is there a way do configure an entire application to treat all requests this way?
Indeed, JSF as being a form based application targeted MVC framework submits the POST form to the very same URL as where the page with the <h:form> is been requested form. You can confirm it by looking at the <form action> URL of the generated HTML output. This is in web development terms characterized as postback. A navigation on a postback does by default not cause a new request to the new URL, but instead loads the target page as content of the response. This is indeed confusing when you merely want page-to-page navigation.
Generally, the right approach as to navigation/redirection depends on the business requirements and the idempotence (read: "bookmarkability") of the request (note: for concrete code examples, see the "See also" links below).
If the request is idempotent, just use a GET form/link instead of POST form (i.e. use <a>, <form>, <h:link> or <h:button> instead of <h:form> and <h:commandXxx>).
For example, page-to-page navigation, Google-like search form, etc.
If the request is non-idempotent, just show results conditionally in the same view (i.e. return null or void from action method and make use of e.g. <h:message(s)> and/or rendered).
For example, in-page data entry/edit, multi-step wizard, modal dialog, confirmation form, etc.
If the request is non-idempotent, but the target page is idempotent, just send a redirect after POST (i.e. return outcome with ?faces-redirect=true from action method, or manually invoke ExternalContext#redirect(), or put <redirect/> in legacy XML navigation case).
For example, showing list of all data after successful editing, redirect after login, etc.
Note that pure page-to-page navigation is usually idempotent and this is where many JSF starters fail by abusing command links/buttons for that and then complain afterwards that URLs don't change. Also note that navigation cases are very rarely used in real world applications which are developed with respect to SEO/UX and this is where many JSF tutorials fail by letting the readers believe otherwise.
Also note that using POST is absolutely not "more secure" than GET because the request parameters aren't immediately visible in URL. They are still visible in HTTP request body and still manipulatable. So there's absolutely no reason to prefer POST for idempotent requests for the sake of "security". The real security is in using HTTPS instead of HTTP and checking in business service methods if currently logged-in user is allowed to query entity X, or to manipulate entity X, etc. A decent security framework offers annotations for this.
See also:
What is the difference between redirect and navigation/forward and when to use what?
JSF implicit vs. explicit navigation
What URL to use to link / navigate to other JSF pages
Bookmarkability via View Parameters feature
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
When should I use h:outputLink instead of h:commandLink?
Creating master-detail pages for entities, how to link them and which bean scope to choose
Retaining GET request query string parameters on JSF form submit
Pass an object between #ViewScoped beans without using GET params
How can i get the page URL in single-approver-definition.xml in the e-mail template that is used to send an e-mail to the content creator once the reviewer approves or rejects the submission. The existing xml is as follows:
<template>
Your submission has been reviewed and the reviewer has applied the following:
${taskComments}.
</template>
I tried ${serviceContext.getAttribute("contentURL")} and it didn't work.
I want to be able to do - Your submission for ${pageURL} has been reviewed and the reviewier has applied the following: \n ${taskComments}.\n
Any suggestions will be appreciated.
I don't get what variable exactly you want to process in your notification. As I can only assume, you are using it for Web Contents and all interesting variables are stored in two places.
Workflow context variables - they are available directly. Few examples like:
${taskComments}
${entryType}
${userId}
${userName}
...
ServiceContext variables - they are available using $serviceContext. Few examples:
$serviceContext.getAttributes().get("version")
$serviceContext.getAttributes().get("articleId")
${serviceContext.getPortalURL()}
...
For all interesting variables check this url https://www.liferay.com/web/igor.beslic/blog/-/blogs/workflow-in-action-kaleo-workflow-context-variables Some could change already, however most of them is working fine for current version.
Content changes might be made on a page, they can also be triggered through Control Panel (or the API for that matter). When you're in a workflow, you typically don't have this context any more - if you find it somehow I'd not rely on it to be there. A workflow is unrelated to the UI and pages.
Also, an article might be submitted on one page, where it might be replaced/removed before it's even approved. In that case the link wouldn't help.
What might work is to check the concept behind "Web Content Display Pages" (if your article has them configured and you deal with web content). But the mechanics will vary depending on the actual content type you're dealing with. And content that goes through workflow might not be displayed on any page at all (e.g. when submitted through Control Panel) or on many different pages (either explicitly - Web Content Display - or implicitly - Asset Publisher).
#tomic basically provides pointers to what you have, I'm only reasoning why your initial problem is problematic to solve at best - it's not fully specifiable.
Hi All
I have a requirement like, from some web page on some event user will redirect to MyApp's login page with some parameter. I want to test MyApp is able to get that parameter or not. To test that i made another app in which i am using (code is below ). But this is showing parameter in url which i don't want. I also want to know what other ways are there to redirect/forward to some another url with parameter ( parameter should be hidden hiddn ).
<%
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location","http://localhost:8080/MyApp/login/login.jsf?user_id=inc&reference_id=123456789");
%> THANKS
It's not possible to do POST redirects, so you can't just redirect with a POST from your scriptlet.
What you can do is:
Build an HTML form in POST with the parameters that you want to pass, but remember, the POST perceived security is brittle, since with a tool like firebug anyone can see those variables (or they can just look at the html source).
A way around the problem is use encryption or one time passwords (that last for a session). I used this way, to connect seamlessly a Java application with PHP. If you're interested I could look it up and share the details of that solution.
First of all, do not use scriptlets. If you dont want to see the parameter in the URL, don't send it with the URL. You can do a POST submit or pass it as a hidden variable from your page.
UPDATE: this has just started happening again, would appreciate any help.
I am using server fbml to render an Invite Friends iframe and it was working fine up until two days ago. Basically, after submitting the form, a java action should be invoked where I get all the id's of the user's invited.
However, I now notice that an "invite by email" popup is showing up and, most importantly, my java action isn't being hit at all. When I inspect the form in firebug, I notice that the action is always empty (though all other parameters are preserved correctly).
I've tried setting email_invite=false on the multi-friend-selctor but to no avail.
My code looks like the following:
<fb:fbml>
<fb:request-form action="http://localhost:8080/myAction.do?method=someAction" method="POST" invite="false" target="_top" type="invite" content="CONTENT_GOES_HERE" >
<fb:multi-friend-selector showborder="false" actiontext="Invite your friends to use our app." target="_top" email_invite="false">
</fb:request-form>
</fb:fbml>
</script>
Any help would be greatly appreciated on this.
UPDATE: this has just started happening again, would appreciate any help.
Thanks, gearoid.
Facebook have recently added an extra step into the multi-friend selector process, which is what you're seeing. There isn't, as far as I know, any way to stop this from appearing.
However, you should still be getting the result of the selector sent to you once the user navigates away from the "invite by email" popup.
Facebook's latest update can be seen in this status post.
To prevent that popup appearing add this attribute to the multi friend selector
import_external_friends="false"
Turns out this can happen a lot of different ways.
A) You can call FB.init multiple times
B) Call FB.init with the wrong key
C) You can supply a action that doesn't map to your current application on facebook
D) You or your staff can accidentially supply the same canvas/app url for two apps.
Most of of the solutions online point at A-C. When someone accidentally creates a second dev app pointing at localhost or 127.0.0.1 as the canvas url for multiple apps you admin you will get hosed. Took me hours upon hours to think to search our other apps. So i hope this saves someone a truck load of time. Cheers
I had an incorrect appId set in the fb-root javascript. This caused the error.
I have a page called Orders and a page called OrderDetails. As described in the excellent MVP tutorial I'm working with History (with a central ValueChangeListener) and an "event bus" HandlerManager.
I have a handler registered for the event that someone clicks on an order, which basically creates the OrderDetailPresenter, passes in the order ID (which is contained in the ShowOrderDetailEvent), and then calls History.newItem("orderDetails").
This has a couple major disadvantages: This newly created History step does NOT know which order ID was passed in. So for example, if someone bookmarks the order details page (or goes back then forward in their browser), they'll get an empty page with no order details.
So my question is: Should I instead do something like History.newItem("orderDetails?id="+id), and then parse the history token in my value change listener? If so, is there a best practice, an API, or library for parsing and formatting arguments into a string in this way?
Yes, that's what you should do. There is, so far as I know, no library for making this easier.
A bit of advice, though: if at all possible, you should avoid using a scheme that requires you to use percent escapes in your history item string. The reason is that what location.hash returns when location.href ends in, say #%3C#%40 varies from browser to browser. For example, Chrome returns #%3C#%40; Firefox returns #<##. Setting location.hash can have similar browser-specific effects.
GWT's History token mechanism relies on location.hash and doesn't normalize this difference in browser behavior. The end result is that if you use something that requires percent escapes, you will get urls that can't be shared across browsers - this is an issue if on some other page you want to generate links that jump to a particular spot within your GWT app, or if you expect users to share URLs that link to within your GWT app. (or when your user installs Chrome, imports their bookmarks from Firefox that pointed to particular spots inside your webapp, and suddenly the bookmarks don't work as they did before)
For paranoia, I'd avoid putting any ?, #, &, %, <, or > characters in your history token string. However, strings like orderDetails/oid=12313378 should be fine, and cross-browser.
(Edited to clarify that the issue I'm talking about is dealing with having identical URLs work in multiple different browsers, not of having the history token method work at all in each of the various browsers)