[jira] Created: (TAP5-613) Returning a Link to a secure page from an ajax event handler method causes the redirect to be invalid if the event is sent from an insecure page
Returning a Link to a secure page from an ajax event handler method causes the redirect to be invalid if the event is sent from an insecure page Key: TAP5-613 URL: https://issues.apache.org/jira/browse/TAP5-613 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.0.18 Reporter: Olaf Tomczak I think there's something wrong with the way tapestry handles redirects from Ajax requests. I'm having the following problem: I have a page, say: http://localhost/mytapestryapp/resetpassword with a form that sends an ajax submit request and the request handler returns a Link which leads to my login page annotated with @Secure. The link factory therefore creates an absolute link like this: https://localhost/mytapestryapp/login/confirmpasswordreset Unfortunately javascript code in tapestry.js uses location.pathname (which afaik changes only the context path of the location) to set the redirect address. The result is that I'm being redirected to the following page: http://localhost/https://localhost/mytapestryapp/login/confirmpasswordreset It works this way on IE and mozilla-based browsers - checked it on Firefox 3.0.7, Epiphany 2.24.3, IE 6.0. It does however work correctly on Opera 9.6 probably because of the differences in how location.pathname is handled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-612) URLRewriting should distinguish between incoming and outgoing requests
[ https://issues.apache.org/jira/browse/TAP5-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12694092#action_12694092 ] Thiago H. de Paula Figueiredo commented on TAP5-612: I vote for #3, as it is by far the more flexible approach, the easiest to write rules and test them. It could include, for example, a method that tells if that given request is an event one or a page one. As generated link rewriting works by decorating ComponentEventLinkEncoder, this is easy to do (different methods for generating page links and event links) and helps some usecases described in the mailing list. URLRewriting should distinguish between incoming and outgoing requests -- Key: TAP5-612 URL: https://issues.apache.org/jira/browse/TAP5-612 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.1.0.2 Reporter: Robert Zeigler Assignee: Robert Zeigler Currently, the new URLRewriting support uses a single method on the set of rewrite rules called process. This method is called both for transforming incoming request urls and for rewriting outbound links. Generally, however, urls from incoming requests are going to be translated into tapestry-aware urls and urls for links will be mapped from tapestry-aware urls to some external form. To facilitate the in vs. out mapping, URL Rewriting should provide a mechanism to distinguish between rewriting incoming urls vs. rewriting links. Three possible ways of doing that are: 1) have a separate service for incoming vs. outgoing rewriting 2) Alter the URLRewriterRule API to change from the single process method to two methods: processIncoming and processOutgoing (or something along those lines) 3) Alter URLRewriterRule API to pass an additional RewriteContext method parameter. The context would include (for now) a single method boolean isIncoming or perhaps boolean isOutgoing. (Alternatively, we could change the method signature to just provide a boolean isOutgoing parameter; but providing the RewriteContext would allow the API to evolve better in the future should we find that additional context information is useful). Currently leaning towards #2. The positive point in #3 could be handled in the future by the introduction of a per-thread helper service, RewriteContext or some such, that could be injected directly into the rewrite rules. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-614) Spacer image should have a blank alt attribute to meet w3c accessability standards
Spacer image should have a blank alt attribute to meet w3c accessability standards -- Key: TAP5-614 URL: https://issues.apache.org/jira/browse/TAP5-614 Project: Tapestry 5 Issue Type: Improvement Components: tapestry-core Affects Versions: 5.0.18, 5.0.17, 5.0.16, 5.0.15, 5.1.0.2, 5.1.0.1, 5.1.0.0 Reporter: Andy Blower Priority: Minor Our User Experience Design team have raised an issue with the use of the tapestry.spacer-image in the Autocomplete mixin. It's also used by the default client side validation. The issue is that the spacer img tag is rendered with no alt attribute which is apparently a problem for these reasons: 1) Always add alt attributes to images. Alt is mandatory for accessibility and for valid (X)HTML. 2) For images that play only a decorative role in the page, use an empty alt (i.e. alt=) or a CSS background image so that reading browsers do not bother users by uttering things like spacer image. So, Tapestry needs to write a blank alt attribute when it uses a spacer gif. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-611) Another way support tapestry.suppress-redirect-from-action-requests.
[
https://issues.apache.org/jira/browse/TAP5-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship closed TAP5-611.
-
Resolution: Won't Fix
Assignee: Howard M. Lewis Ship
You can accomplish this today by returning a Link or URL from an event handler
method.
Another way support tapestry.suppress-redirect-from-action-requests.
Key: TAP5-611
URL: https://issues.apache.org/jira/browse/TAP5-611
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.1.0.0
Reporter: luna Guo
Assignee: Howard M. Lewis Ship
EventLink request URLs can not be bookmarked.For example may user want to
bookmark the 2nd page of a grid.(the list order never change) ,I also like a
redirect after form post.So I don't want to set
tapestry.suppress-redirect-from-action-requests to true.What about set
tapestry.suppress-redirect-from-action-requests default to true, event
handler return a redirect by giving a @Redirect or a @Forward to prevent a
redirect.
@Redirect
void onSuccess(){
...
@Forward
void onActionFromPager(){
...
thanks
luna
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-615) The t:body/ component tag appears to be case sensitive. t:Body/ does not work.
The t:body/ component tag appears to be case sensitive. t:Body/ does not work. -- Key: TAP5-615 URL: https://issues.apache.org/jira/browse/TAP5-615 Project: Tapestry 5 Issue Type: Bug Components: tapestry-core Affects Versions: 5.1.0.1 Reporter: Luther Baker Priority: Trivial Using t:Body/ in a layout template throws the following error: Exception assembling root component of page home/Index: Unable to resolve 'Body' to a component class name. Available component types: ActionLink, AddRowLink, AjaxFormLoop, Any, BeanDisplay, BeanEditForm, BeanEditor, Checkbox, DateField, Delegate, Errors, EventLink, ExceptionDisplay, Form, FormFragment, FormInjector, Grid, GridCell, GridColumns, GridPager, GridRows, If, Label, Layout, LinkSubmit, Loop, Output, OutputRaw, PageLink, Palette, PasswordField, ProgressiveDisplay, PropertyDisplay, PropertyEditor, Radio, RadioGroup, RemoveRowLink, RenderObject, Select, Submit, SubmitNotifier, TextArea, TextField, TextOutput, Unless, Zone. Switch to t:body/ and all is well. Component tags *should* be case-insensitive. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
