Session timeout, Login, POST form resubmission fails about tapestry-security HOT 19 CLOSED

20140411 20:38:05.586 [http-bio-8080-exec-7] ERROR org.apache.tapestry5.ioc.Registry - Forms require that the request method be POST and that the t:formdata query parameter have values.
20140411 20:38:05.587 [http-bio-8080-exec-7] ERROR org.apache.tapestry5.ioc.Registry - Operations trace:
20140411 20:38:05.587 [http-bio-8080-exec-7] ERROR org.apache.tapestry5.ioc.Registry - [ 1] Handling traditional 'action' component event request for company/Profile:companyprofileform.form.
20140411 20:38:05.587 [http-bio-8080-exec-7] ERROR org.apache.tapestry5.ioc.Registry - [ 2] Triggering event 'action' on company/Profile:companyprofileform.form
20140411 20:38:05.597 [http-bio-8080-exec-7] ERROR o.a.t.m.T.RequestExceptionHandler - Processing of request failed with uncaught exception: org.apache.tapestry5.ioc.internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:org/apache/tapestry5/corelib/components/BeanEditForm.tml, line 2]
org.apache.tapestry5.ioc.internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values.
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:180) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:89) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1112) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementResourcesImpl.invoke(ComponentPageElementResourcesImpl.java:154) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1045) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.ComponentEventRequestHandlerImpl.handle(ComponentEventRequestHandlerImpl.java:75) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.AjaxFilter.handle(AjaxFilter.java:42) ~[tapestry-core-5.4-beta-4.jar:na]
at $ComponentEventRequestHandler_22af76ec4e2c4.handle(Unknown Source) ~[na:na]
at org.apache.tapestry5.modules.TapestryModule$37.handle(TapestryModule.java:2199) ~[tapestry-core-5.4-beta-4.jar:na]
at $ComponentEventRequestHandler_22af76ec4e2c4.handle(Unknown Source) ~[na:na]
at $ComponentEventRequestHandler_22af76ec4e1f1.handle(Unknown Source) ~[na:na]
at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handleComponentEvent(ComponentRequestHandlerTerminator.java:43) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39) ~[tapestry-core-5.4-beta-4.jar:na]
at $ComponentRequestHandler_22af76ec4e1f3.handleComponentEvent(Unknown Source) ~[na:na]
at org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:55) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.RequestOperationTracker$1.perform(RequestOperationTracker.java:52) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.perform(OperationTrackerImpl.java:107) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.perform(PerThreadOperationTracker.java:100) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.RegistryImpl.perform(RegistryImpl.java:1117) ~[tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.RequestOperationTracker.handleComponentEvent(RequestOperationTracker.java:47) ~[tapestry-core-5.4-beta-4.jar:na]
at $ComponentRequestHandler_22af76ec4e1f3.handleComponentEvent(Unknown Source) ~[na:na]
at org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:41) ~[tapestry-security-0.6.1-SNAPSHOT.jar:0.6.1-SNAPSHOT]
at $ComponentRequestFilter_22af76ec4e1f0.handleComponentEvent(Unknown Source) ~[na:na]
at $ComponentRequestHandler_22af76ec4e1f3.handleComponentEvent(Unknown Source) ~[na:na]
at $ComponentRequestHandler_22af76ec4e1c3.handleComponentEvent(Unknown Source) ~[na:na]
at org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:46) ~[tapestry-core-5.4-beta-4.jar:na]
at $Dispatcher_22af76ec4e1c5.dispatch(Unknown Source) ~[na:na]
at $Dispatcher_22af76ec4e1bc.dispatch(Unknown Source) ~[na:na]
at org.apache.tapestry5.modules.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:300) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) ~[tapestry-core-5.4-beta-4.jar:na]
at $RequestHandler_22af76ec4e1bd.service(Unknown Source) [na:na]
at org.apache.tapestry5.modules.TapestryModule$3.service(TapestryModule.java:847) [tapestry-core-5.4-beta-4.jar:na]
at $RequestHandler_22af76ec4e1bd.service(Unknown Source) [na:na]
at org.apache.tapestry5.modules.TapestryModule$2.service(TapestryModule.java:837) [tapestry-core-5.4-beta-4.jar:na]
at $RequestHandler_22af76ec4e1bd.service(Unknown Source) [na:na]
at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:89) [tapestry-core-5.4-beta-4.jar:na]
at $RequestHandler_22af76ec4e1bd.service(Unknown Source) [na:na]
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:105) [tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter$2.invoke(CheckForUpdatesFilter.java:95) [tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.util.ConcurrentBarrier.withRead(ConcurrentBarrier.java:85) [tapestry-ioc-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.services.CheckForUpdatesFilter.service(CheckForUpdatesFilter.java:119) [tapestry-core-5.4-beta-4.jar:na]
at $RequestHandler_22af76ec4e1bd.service(Unknown Source) [na:na]
at $RequestHandler_22af76ec4e1aa.service(Unknown Source) [na:na]
at org.apache.tapestry5.modules.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:251) [tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59) [tapestry-core-5.4-beta-4.jar:na]
at $HttpServletRequestHandler_22af76ec4e1ac.service(Unknown Source) [na:na]
at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) [tapestry-core-5.4-beta-4.jar:na]
at $HttpServletRequestFilter_22af76ec4e1a8.service(Unknown Source) [na:na]
at $HttpServletRequestHandler_22af76ec4e1ac.service(Unknown Source) [na:na]
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:56) [tapestry-security-0.6.1-SNAPSHOT.jar:0.6.1-SNAPSHOT]
at org.tynamo.security.services.impl.SecurityConfiguration$1.call(SecurityConfiguration.java:54) [tapestry-security-0.6.1-SNAPSHOT.jar:0.6.1-SNAPSHOT]
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) [shiro-core-1.2.3.jar:1.2.3]
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) [shiro-core-1.2.3.jar:1.2.3]
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383) [shiro-core-1.2.3.jar:1.2.3]
at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54) [tapestry-security-0.6.1-SNAPSHOT.jar:0.6.1-SNAPSHOT]
at $HttpServletRequestFilter_22af76ec4e1a7.service(Unknown Source) [na:na]
at $HttpServletRequestHandler_22af76ec4e1ac.service(Unknown Source) [na:na]
at org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:797) [tapestry-core-5.4-beta-4.jar:na]
at $HttpServletRequestHandler_22af76ec4e1ac.service(Unknown Source) [na:na]
at $HttpServletRequestHandler_22af76ec4e1a6.service(Unknown Source) [na:na]
at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166) [tapestry-core-5.4-beta-4.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) [catalina.jar:7.0.47]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) [catalina.jar:7.0.47]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) [catalina.jar:7.0.47]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) [catalina.jar:7.0.47]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502) [catalina.jar:7.0.47]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) [catalina.jar:7.0.47]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) [catalina.jar:7.0.47]
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) [catalina.jar:7.0.47]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) [catalina.jar:7.0.47]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) [catalina.jar:7.0.47]
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041) [tomcat-coyote.jar:7.0.47]
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) [tomcat-coyote.jar:7.0.47]
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) [tomcat-coyote.jar:7.0.47]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
Caused by: org.apache.tapestry5.runtime.ComponentEventException: Forms require that the request method be POST and that the t:formdata query parameter have values.
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.processEventTriggering(ComponentPageElementImpl.java:1128) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.access$3100(ComponentPageElementImpl.java:59) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$5.invoke(ComponentPageElementImpl.java:1049) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl$5.invoke(ComponentPageElementImpl.java:1046) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:80) ~[tapestry-ioc-5.4-beta-4.jar:na]
... 76 common frames omitted
Caused by: java.lang.RuntimeException: Forms require that the request method be POST and that the t:formdata query parameter have values.
at org.apache.tapestry5.corelib.components.Form.executeStoredActions(Form.java:632) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.corelib.components.Form.onAction(Form.java:499) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.corelib.components.Form.dispatchComponentEvent(Form.java) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.dispatchEvent(ComponentPageElementImpl.java:919) ~[tapestry-core-5.4-beta-4.jar:na]
at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.processEventTriggering(ComponentPageElementImpl.java:1104) ~[tapestry-core-5.4-beta-4.jar:na]
... 80 common frames omitted

from tapestry-security.

We are currently doing a 302 redirect which obviously is wrong in this case as it results in GET. What are you suggesting, remembering method and doing a 307 (see http://stackoverflow.com/questions/17605915/what-is-the-correct-behavior-expected-of-an-http-post-302-redirect-to-get)? That may fail as well depending on the session state. A bullet proof solution is out of scope for a security library, but I'm happy to support an improvement.

from tapestry-security.

I've implemented simple workaround for this situation: on saving request
cookie we can determine if current request is POST or if it's event request
(like from event link). In this case I'm replacing saved request cookie
with corresponding page render link:

https://gist.github.com/dmitrygusev/10573547

On Sun, Apr 13, 2014 at 10:46 AM, Kalle Korhonen
[email protected]:

We are currently doing a 302 redirect which obviously is wrong in this
case as it results in GET. What are you suggesting, remembering method and
doing a 307 (see
http://stackoverflow.com/questions/17605915/what-is-the-correct-behavior-expected-of-an-http-post-302-redirect-to-get)?
That may fail as well depending on the session state. A bullet proof
solution is out of scope for a security library, but I'm happy to support
an improvement.

Reply to this email directly or view it on GitHubhttps://github.com//issues/7#issuecomment-40300924
.

Dmitry Gusev

AnjLab Team
http://anjlab.com

from tapestry-security.

Hmm I like @dmitrygusev 's solution and given I didn't hear anything from @balapal, I think doing a page refresh instead for the POST is a reasonable improvement. Again, since application needs vary, it's far easier to handle session expiration in applications on case by case basis rather than try to come up with a configuration mechanism for a library that would do "the right thing" in all cases.

from tapestry-security.

I haven't looked at the code too closely, but maybe you could add a chain of command in the place where the request is handled. Then it would be easy to add custom behavior in an application if you want to, but provide a sensible default behavior.

from tapestry-security.

My point is that if you are let's say writing a long comment. Just before finishing you get distracted for an hour. When you get back you finish it and submit it, because your session has expired you lose your comment.
Of course you can argue how do we know if the same user logged in again, but I think it would be a sensible default behaviour to do a POST request upon successful login.

from tapestry-security.

@balapal, yes I understand but this function is hardly the responsibility of a security library. In fact, that exact use case was the main motivation when I created http://tynamo.org/tapestry-conversations+guide. Furthermore, if you read what I said about POST above, there's simply no way to just redo a POST request since we don't have the body of the original request anymore. @jochenberger, the code in question is very simple right now and I'm somewhat doubtful that is the right extension point for any extensive behavior customization.

from tapestry-security.

The fix has a problem. when I post to /app/page/context after the session has expired, I'm redirected to /app/app/page/context (note the additional app).

from tapestry-security.

Uh yeah, I can already see why that happened but odd that the test didn't catch it, I thought we had one for that exact case. Re-opening.

from tapestry-security.

I had a quick glance and I think the problem is that the test uses contains instead of equals.

from tapestry-security.

No, the context path is not anymore manually added to the request anywhere. Yes, using the contains in testUserFilterWithAjaxDeny seems to only partially assert the correct url but testSaveRequestFilter has it right and I checked that the context is not duplicated in either of those tests. I don't see how making a POST would be any different. Can you provide a test case? Is this in your application, have you made any customization? There's been various small changes in how the saved request is handled in the previous versions.

from tapestry-security.

I thought you already knew what the problem is.
I can have a look but I don't know the cause either and at the moment, I don't have the time to look into it.
I guess it only happens if the context path is not '/', maybe it needs to be stripped from the request URL somewhere.

from tapestry-security.

I suspected something but my hunch was wrong. The tests are run on context path /test so not sure now where the problem is.

from tapestry-security.

The problem is in LoginContextServiceImpl:179:

WebUtils.issueRedirect(servletRequest, servletResponse, requestUri);

That method assumes that the URL is relative to the context. Then, org.apache.shiro.web.util.RedirectView:197 prepends (incorrectly IMO) the context path to the redirect URL. I think that's a bug in Shiro, I guess it should read

if (this.contextRelative && !(getUrl().startsWith("/"))) {`

You should be fine if you change the redirect to

WebUtils.issueRedirect(servletRequest, servletResponse, requestUri, null, false, true);

from tapestry-security.

Thanks, excellent work tracking that down. That causes the issue in part but it's not a bug in Shiro. According to the servlet spec, HttpServletResponse.sendRedirect() is supposed to handle relative URLs to the current request. That certainly doesn't make sense with Tapestry (does it ever?) but that's why the condition is written as it is. There's perhaps no reason to use the whole Shiro redirecting machinery in tapestry-security but I'll see about it. Also, need to check why the integration tests don't catch this.

from tapestry-security.

I was going to close this but upon closer examination, the problem really is directly caused by the commit 8e5384a for this issue. The bug is caused by incoherently saving context path with some requests and leaving it out from others and it already existed in @dmitrygusev 's original gist and while we have tests for this, they were written just so this this slipped through. Decided to address it as part of the new issue #15 anyway for better traceability.

from tapestry-security.

This is regarding the compatibility of Java 8 with Tapestry 3.0.3. We have an application which is built in Java 6 and Tapestry 3.0.3.
While upgrading the application to Java 8, we got the below error.

[Error] Unable to resolve expression 'tableRowsIterator' for org.apache.tapestry.contrib.table.components.TableRows$Enhance_45@19a5b30[MyCalculations/table.tableRows].
org.apache.tapestry.BindingException: Unable to resolve expression 'tableRowsIterator' for org.apache.tapestry.contrib.table.components.TableRows$Enhance_45@19a5b30[MyCalculations/table.tableRows].
at org.apache.tapestry.binding.ExpressionBinding.resolveProperty(ExpressionBinding.java:205)

Just wanted to check if it is really possible to upgrade the application to Java 8 with Tapestry 3.0.3.

from tapestry-security.

Huh @kradhakr? Totally wrong place, you added a comment on unrelated issue that was closed two years ago and on top of that, Tynamo never supported Tapestry 3.x.

from tapestry-security.

OK.Can you tell me who can help in this?
On Jun 14, 2016 4:02 PM, "Kalle Korhonen" [email protected] wrote:

Huh @kradhakr https://github.com/kradhakr? Totally wrong place, you
added a comment on unrelated issue that was closed two years ago and on top
of that, Tynamo never supported Tapestry 3.x.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ATAPfx0N0u3F1MY999zLvLxUbnYozElfks5qLrSBgaJpZM4Bx0oG
.

from tapestry-security.