[jira] Created: (TAP5-827) Validation error popup bubbles is overlapped by select box in IE6
Validation error popup bubbles is overlapped by select box in IE6
-
Key: TAP5-827
URL: https://issues.apache.org/jira/browse/TAP5-827
Project: Tapestry 5
Issue Type: Improvement
Affects Versions: 5.1.0.5
Reporter: maxyu
Priority: Minor
Validation error popup bubbles will be overlapped by a select box up to it.
This is an IE6 bug which cause div overlapped by select box. To overcome it, an
iframe should be used to overlapped select box which has -1 as z-index to bring
error message to the foreground.
I just modify the tapestry.js to solve this problem.
In ErrorPopup's initialize method, we should not add span direct into the
errorpopup div,but a div with iframe and inner div(which contains the span) in
it.
this.innerSpan = new Element("span");
this.innerframe=new Element("iframe",
{
'style':"position:absolute;z-index:-1;width:100%;height:100%;top:0;left:0;",
'frameborder':"0",
'src':"",
'scrolling':"no"
});
this.innerdiv=new Element("div");
this.innerdiv.update(this.innerSpan);
this.outerDiv = $(new Element("div", {
'id' : this.field.id + ":errorpopup",
'class' : 't-error-popup'
})).update(this.innerframe).hide();
this.outerDiv.appendChild(this.innerdiv);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748057#action_12748057 ] Ulrich Stärk commented on TAP5-815: --- I had some singleton service holding a collection of allowed assets in mind. This would be injected into AssetSource and queried whether access should be allowed. Allowde Assets get added from AssetObjectProvider, AssetInjectionProvider, IncludeJavaScriptLibraryWorker, IncludeStylesheetWorker, ContextBindingFactory and AssetBindingFactory. If people choose to override the default AssetSource they have to live with being responsible for taking care of security. We could btw. also do the checks in the corresponding AssetFactories. Uli > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748050#action_12748050 ] Robert Zeigler commented on TAP5-815: - Ulrich, "Just allow access to Assets really required by pages or components" is easier said than done. The assets required by a page are not known until the first time a page is requested and the correspond page model is built. Which means that it's difficult, at best, for an IOC module to access this information at service instantiation time; it will be instantiated when the first request comes in, /before/ the corresponding page is even loaded (due to dispatcher ordering), and that's on the first request, for a single page, before any other pages are loaded. Any sort of asset authorization service that wanted to auto-enable required assets would need to have some sort of "addVisibleResource" method that is called whenever an asset is encountered/created during render. I would advocate instead a whitelist approach where allowed files/file patterns are contributed via ioc contributions. This would simplify things significantly. As for assets used only by components, pages, and mixins, that's also a bit tricky, since it's possible for someone to write an alternative asset source that's used, eg, for file downloads (ie, not necessarily directly referenced by a page/component/mixin). Incidentally, a long while ago, I implemented and made available for public use an "AssetProtectionDispatcher" that is configured essentially via chain of command as specified by Thiago above, with slight variation (a bit more flexible; individual contributions specify whether they explicitly allow or deny access). The module further provides two "AssetPathAuthorizer" implementations: one for explicit whitelisting by resource name, and the other for whitelisting by url pattern, with the whitelist being the last in the chain of command. The module contributes a default set of values to the whitelist (everything used by tapestry's core components), but you'll need to add explicit access to other resources (eg: contributing a .*\.jpg to the RegexAuthorizer). Maven repo: http://maven.saiwai-solutions.com groupid: com.saiwaisolutions artifactid: AssetProtectionDispatcher version: 1.0.0 Alternatively, an older version is available on Tassel: http://saiwai-solutions.com/Tassel/app?service=external/ViewComponent&sp=SAssetProtectionDispatcher Version 1.0.0 also adds some default configurations to handle chenillekit-based assets. Cheers! > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-826) The action link documentation is missing the option to use [param1, param2]
[ https://issues.apache.org/jira/browse/TAP5-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Hennebrueder updated TAP5-826: Attachment: actionlink.xdoc.patch > The action link documentation is missing the option to use [param1, param2] > --- > > Key: TAP5-826 > URL: https://issues.apache.org/jira/browse/TAP5-826 > Project: Tapestry 5 > Issue Type: Improvement > Components: documentation >Affects Versions: 5.1.0.5 >Reporter: Sebastian Hennebrueder > Attachments: actionlink.xdoc.patch > > > Patch is attached but I couldn't test it as somehow building the > documentaiton failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TAP5-826) The action link documentation is missing the option to use [param1, param2]
The action link documentation is missing the option to use [param1, param2] --- Key: TAP5-826 URL: https://issues.apache.org/jira/browse/TAP5-826 Project: Tapestry 5 Issue Type: Improvement Components: documentation Affects Versions: 5.1.0.5 Reporter: Sebastian Hennebrueder Attachments: actionlink.xdoc.patch Patch is attached but I couldn't test it as somehow building the documentaiton failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747895#action_12747895 ] Thiago H. de Paula Figueiredo commented on TAP5-815: I agree with Ulrich. The Tapestry asset handling should only be used by Tapestry components, pages and mixins. > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747889#action_12747889 ] Ulrich Stärk commented on TAP5-815: --- Accessing a Tapestry-managed asset from a non-Tapestry source like a static html file should be avoided IMO. Such assets should be stored in the webapp context and can than be handled by the container and not by Tapestry. > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747886#action_12747886 ] Thiago H. de Paula Figueiredo commented on TAP5-815: I agree with Ulrich that a whitelist approach is probably the best one, but allowing onle access to assets used in pages is too restrictive IMHO. It would make working with anything that isn't a Tapestry page a hassle. I would suggest to have a chain of command, each object in it receiving the requested URL and responding true (ok), false (file is forbidden) or null (this object doesn't handle this URL, ask the same thing to the next object. This chain of command terminator would be a very restrictive one. > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[
https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747829#action_12747829
]
Ilya Obshadko edited comment on TAP5-577 at 8/26/09 1:20 AM:
-
>> The weird thing is what I've done at least half works... when the filter
>> sets the locale, the messages displayed on
>> my page are correctly localised even though the thread locale is
>> subsequently set back to the browser default
>> rather than our persistent locale. I have no idea why this is and I honestly
>> haven't the time or inclination any
>> more to look into this problem more so I'm not going to be finding out.
This is because of the following code in LocalizationSetterImpl
public boolean setLocaleFromLocaleName(String localeName)
{
boolean supported = acceptedLocaleNames.contains(localeName);
if (supported)
{
Locale locale = findClosestSupportedLocale(toLocale(localeName));
persistentLocale.set(locale);
threadLocale.setLocale(locale);
}
else
{
Locale requestLocale = request.getLocale();
//
Locale supportedLocale = findClosestSupportedLocale(requestLocale);
threadLocale.setLocale(supportedLocale);
}
return supported;
}
I found out that during normal request processing this method is being called
even if there is no persistent locale in the URL. So, when URL is, for example,
http://localhost:8080/app/index, the methods takes string "index" as an
argument; then of course it sets supported to false, and eventually falls back
to the request locale.
I believe the whole implementation is flawed; LocalizationSetter implementation
should not guess if it's supplied with locale name or not, the argument must be
valid locale code (already defined in the list of possible locales in
configuration) from the very start. So locale code should be checked for
validity before it's passed to LocalizationSetter.
My solution was just copy-pasting LocalizationSetterImpl; then I've modified
the code so LocalizationSetter would fall back to 'default' locale (first in
supported locales list) rather than request locale; then I've overridden
default LocalizationSetter service. That solved my particular problem (I need
Russian language version of the website by default).
was (Author: xfyre):
The weird thing is what I've done at least half works... when the filter
sets the locale, the messages displayed on my page are correctly localised even
though the thread locale is subsequently set back to the browser default rather
than our persistent locale. I have no idea why this is and I honestly haven't
the time or inclination any more to look into this problem more so I'm not
going to be finding out.
This is because of the following code in LocalizationSetterImpl
public boolean setLocaleFromLocaleName(String localeName)
{
boolean supported = acceptedLocaleNames.contains(localeName);
if (supported)
{
Locale locale = findClosestSupportedLocale(toLocale(localeName));
persistentLocale.set(locale);
threadLocale.setLocale(locale);
}
else
{
Locale requestLocale = request.getLocale();
//
Locale supportedLocale = findClosestSupportedLocale(requestLocale);
threadLocale.setLocale(supportedLocale);
}
return supported;
}
I found out that during normal request processing this method is being called
even if there is no persistent locale in the URL. So, when URL is, for example,
http://localhost:8080/app/index, the methods takes string "index" as an
argument; then of course it sets supported to false, and eventually falls back
to the request locale.
I believe the whole implementation is flawed; LocalizationSetter implementation
should not guess if it's supplied with locale name or not, the argument must be
valid locale code (already defined in the list of possible locales in
configuration) from the very start. So locale code should be checked for
validity before it's passed to LocalizationSetter.
My solution was just copy-pasting LocalizationSetterImpl; then I've modified
the code so LocalizationSetter would fall back to 'default' locale (first in
supported locales list) rather than request locale. That solved my particular
problem (I need Russian language version of the website by default).
> TAP5-422 changes break persistent locale backwards compatibility.
> -
>
> Key: TAP5-577
> URL: https://issues.apache.org/jira/browse/TAP5-577
> Project: Tapestry 5
> Issue Type: Bug
> Co
[jira] Commented: (TAP5-577) TAP5-422 changes break persistent locale backwards compatibility.
[
https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747829#action_12747829
]
Ilya Obshadko commented on TAP5-577:
The weird thing is what I've done at least half works... when the filter
sets the locale, the messages displayed on my page are correctly localised even
though the thread locale is subsequently set back to the browser default rather
than our persistent locale. I have no idea why this is and I honestly haven't
the time or inclination any more to look into this problem more so I'm not
going to be finding out.
This is because of the following code in LocalizationSetterImpl
public boolean setLocaleFromLocaleName(String localeName)
{
boolean supported = acceptedLocaleNames.contains(localeName);
if (supported)
{
Locale locale = findClosestSupportedLocale(toLocale(localeName));
persistentLocale.set(locale);
threadLocale.setLocale(locale);
}
else
{
Locale requestLocale = request.getLocale();
//
Locale supportedLocale = findClosestSupportedLocale(requestLocale);
threadLocale.setLocale(supportedLocale);
}
return supported;
}
I found out that during normal request processing this method is being called
even if there is no persistent locale in the URL. So, when URL is, for example,
http://localhost:8080/app/index, the methods takes string "index" as an
argument; then of course it sets supported to false, and eventually falls back
to the request locale.
I believe the whole implementation is flawed; LocalizationSetter implementation
should not guess if it's supplied with locale name or not, the argument must be
valid locale code (already defined in the list of possible locales in
configuration) from the very start. So locale code should be checked for
validity before it's passed to LocalizationSetter.
My solution was just copy-pasting LocalizationSetterImpl; then I've modified
the code so LocalizationSetter would fall back to 'default' locale (first in
supported locales list) rather than request locale. That solved my particular
problem (I need Russian language version of the website by default).
> TAP5-422 changes break persistent locale backwards compatibility.
> -
>
> Key: TAP5-577
> URL: https://issues.apache.org/jira/browse/TAP5-577
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
>Affects Versions: 5.1.0.0, 5.1.0.1
>Reporter: Andy Blower
>Priority: Critical
> Attachments: T5.1persistentLocale.txt
>
>
> I think that the changes made in T5.1 for TAP5-422 break backwards
> compatibility with T5.0's locale persistence. In T5.0 it was a simple matter
> to override the default cookie persistence by creating a custom
> implementation of the PersistentLocale service and contributing it to be used
> instead of the standard internal T5 implementation.
> The TAP5-422 changes broke backwards compatibility because anyone who's
> created their own implementation of PersistentLocale, or just wants the 5.0
> cookie persistence behaviour, would have found that it's a lot more work and
> involves some heavy changes to Tapestry internals. Now with the recent
> changes for TAP5-418 (committed yesterday), the situation had been alleviated
> somewhat by allowing the the hard-wired URl locale persistence to be switched
> off using a new symbol.
> However, I still think that this breaks backwards compatibility in two ways:
> 1) By changing the default behaviour of locale persistence so that anyone
> relying on the locale persistence behaviour of 5.0 will have to make
> non-trivial changes when they upgrade to 5.1 to keep the same operation.
> 2) By requiring so much work for anyone wanting to keep the 5.0 cookie
> persistence behaviour or define their own custom locale persistence. (In 5.0
> it was easy to figure out and implement a custom locale persistence method)
> From my analysis of the changes made by TAP5-422 & TAP5-418, I think anyone
> wanting non-URL based locale persistence will need to do the following when
> upgrading from 5.0 to 5.1:
> 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false.
> 2) Create an implementation of PersistentLocale and contribute it to the IOC.
> (copied from the standard 5.0 code if the old default cookie persistence is
> desired)
> 3) Create a custom filter written and created to do the same job as the 5.0
> LocalizationFilter and contribute it to the IOC RequestHandler. This filter
> will need to call the LocalizationSetter setLocaleFromLocaleName() method
> instead of the old setThreadLocale() method.
> My suggested resolution would be to
[jira] Commented: (TAP5-815) Asset dispatcher allows any file inside the webapp visible and downloadable
[ https://issues.apache.org/jira/browse/TAP5-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747826#action_12747826 ] Ulrich Stärk commented on TAP5-815: --- In 5.2-SNAPSHOT you can still access files located on the classpath or in the webapp context, except for .class und .tml files in the classpath (due to ResourceDigestGenerator). .tml files in the context are still accessible. There is no directory listing though. So this also partly applies to the current development tree. The problem here is that Tapestry is using a blacklisting approach: It allows all access unless otherwise specified, for example by contributing to the ResourceDigestGenerator. This principle is unsecure by design. Instead Tapestry should do whitelisting, i.e. only allow access to explicitly allowed resources. Since Tapestry already knows about all the Assets required by a page or component (by looking at the @Path, @IncludeJavaScriptLibrary and @IncludeStylesheet annotations and the context: and asset: binding prefixes), such a whitelisting approach could be realized: Just allow access to Assets really required by pages or components. > Asset dispatcher allows any file inside the webapp visible and downloadable > --- > > Key: TAP5-815 > URL: https://issues.apache.org/jira/browse/TAP5-815 > Project: Tapestry 5 > Issue Type: Bug >Affects Versions: 5.1.0.5 >Reporter: Thiago H. de Paula Figueiredo >Priority: Blocker > > Take any asset and you have an URL like > domain.com/assets/ctx/f10407a6c1753e39/css/main.css. If you request > domain.com/assets/ctx/f10407a6c1753e39/, a list containing all the files > inside the webapp root is shown. It gives you the hint at downloading any > file you want, including anyting inside WEB-INF and assets that should be > protected by ResourceDigestGenerator. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
