June 2010 - seam-issues - Jboss List Archives

[JBoss JIRA] Created: (SEAMFACES-43) UIInputContainer should come with a standard implementation. (include example p:input from booking example)

by Lincoln Baxter III (JIRA)

UIInputContainer should come with a standard implementation. (include example p:input from booking example) ----------------------------------------------------------------------------------------------------------- Key: SEAMFACES-43 URL: https://jira.jboss.org/browse/SEAMFACES-43 Project: Seam Faces Issue Type: Feature Request Components: UI Components Affects Versions: 3.0.0.Alpha3 Reporter: Lincoln Baxter III Fix For: 3.0.0.Alpha4 The <p:input> decorator tag should be included under /src/main/resources/property/input.xhtml This implementation is good enough to be provided as a default in Seam Faces -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
8
0 / 0

[JBoss JIRA] Created: (SEAMFACES-40) Cannot extend validators with @Inject @InputField in the parent class

by Lincoln Baxter III (JIRA)

Cannot extend validators with @Inject @InputField in the parent class --------------------------------------------------------------------- Key: SEAMFACES-40 URL: https://jira.jboss.org/browse/SEAMFACES-40 Project: Seam Faces Issue Type: Bug Components: UI Components, Validation & Conversion Affects Versions: 3.0.0.Alpha3 Reporter: Lincoln Baxter III FormValidationTypeOverrideExtension is only adding meta-data for top-level classes, not their children, so inherited @Inject @InputField elements are not being updated, which causes UnsatisfiedDependencyExceptions due to typing mismatches. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBSEAM-4655) Custom EntityIdentifierStrategy ignored by IdentifierPolicy

by Robert Raksi (JIRA)

Custom EntityIdentifierStrategy ignored by IdentifierPolicy ----------------------------------------------------------- Key: JBSEAM-4655 URL: https://jira.jboss.org/browse/JBSEAM-4655 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.2.0.GA Reporter: Robert Raksi I tried to set a custom identifier strategy for one of my entities with the @Identifier annotation but after debuging the IdentifierPolicy class I found that my custom strategy is neglected in favor of the builtin EntityIdentifierStrategy. Inside the if (strategy == null) {} block my strategy is found and put into the strategies map as expected but then in the for statement it's replaced with de default one. Shouldn't the for statement be in an else block? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
3
0 / 0

[JBoss JIRA] Created: (JBSEAM-4659) RememberMe fails to add Cookie because of invalid Base64 encoding

by Florian Specker (JIRA)

RememberMe fails to add Cookie because of invalid Base64 encoding ----------------------------------------------------------------- Key: JBSEAM-4659 URL: https://jira.jboss.org/browse/JBSEAM-4659 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.2.0.GA Reporter: Florian Specker RememberMe.encodeToken() uses Base64 to encode Cookie values before actually adding the Cookie. For long usernames, a newline char (\n) is inserted, preventing the Cookie from being added. JBREM-806 addressed the same issue for JBoss remoting: [..] --------- Solution: org.jboss.util.Base64.encodeBytes() takes an optional "options" parameter, which, among other things, can indicate that Base64 encoded strings should not be broken into lines: change String encoded = Base64.encodeBytes(buffer.toString().getBytes()); to String encoded = Base64.encodeBytes(buffer.toString().getBytes(), Base64.DONT_BREAK_LINES); [..] As a workaround, I subclassed RememberMe and overwrote encodeToken(): @Override protected String encodeToken(String username, String value) { StringBuilder sb = new StringBuilder(); sb.append(username); sb.append(":"); sb.append(value); // do not break lines - this results in invalid cookies return Base64.encodeBytes(sb.toString().getBytes(), Base64.DONT_BREAK_LINES); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4248) Messages component gets wrong locale in when called with seam remoting (@WebRemote)

by David Jensen (JIRA)

Messages component gets wrong locale in when called with seam remoting (@WebRemote) ----------------------------------------------------------------------------------- Key: JBSEAM-4248 URL: https://jira.jboss.org/jira/browse/JBSEAM-4248 Project: Seam Issue Type: Bug Components: Remoting Affects Versions: 2.1.2.GA Environment: Seam 2.1.2.GA, JBoss EAP 4.3 Reporter: David Jensen Assignee: Shane Bryzak The wrong locale gets set when using the 'Messages' component in a @WebRemote method called from javascript. Regardless of supported and default locales in faces-config.xml whatever the browser requests is used. I'll attach a clean project with code example. Basically I hunted it down to org.jboss.seam.international.LocaleSelector.getLocale() where we get the locale from the HttpRequest since no FacesContext exists. It would seem you can only have supported and default locales in a ordinary JSF request, It would be nice if Seam could keep of track that for you instead of JSF, or have I misunderstood something? Thanks! /David -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2820) Remoting should not throw exception but 400/404 on invalid request

by Christian Bauer (JIRA)

Remoting should not throw exception but 400/404 on invalid request ------------------------------------------------------------------ Key: JBSEAM-2820 URL: http://jira.jboss.com/jira/browse/JBSEAM-2820 Project: JBoss Seam Issue Type: Bug Components: Remoting Reporter: Christian Bauer Assigned To: Shane Bryzak Some crazy Java program is making HTTP requests on our live site: 85.82.169.224 - - [04/Apr/2008:15:38:48 +0100] "GET /seam/resource/remoting/interface.js HTTP/1.1" 200 - "null" "Java/1.5.0_13" I'm guessing this is a home-written HTML parser or something from a Danish ;) guy or a website "downloader" or something. In any case, it cuts off the request parameters and we throw an exception: 15:38:48,818 ERROR [Remoting] Error javax.servlet.ServletException: Invalid request - no component specified at org.jboss.seam.remoting.InterfaceGenerator$1.process(InterfaceGenerator.java:73) at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53) at org.jboss.seam.remoting.InterfaceGenerator.handle(InterfaceGenerator.java:64) at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:111) at org.jboss.seam.servlet.SeamResourceServlet.doGet(SeamResourceServlet.java:75) Do not throw an exception but either return 400 INVALID REQUEST or 404 NOT FOUND. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3908) RememberMe on JBoss 5 loses part of the username when formatted as an email address

by Cameron Fieber (JIRA)

RememberMe on JBoss 5 loses part of the username when formatted as an email address ----------------------------------------------------------------------------------- Key: JBSEAM-3908 URL: https://jira.jboss.org/jira/browse/JBSEAM-3908 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.1.GA, 2.1.1.CR1 Environment: JBoss 5.0.0.GA Java 1.6.0_07 Mac OS X 10.5.6 Both Firefox 3.0.5 and Safari 3.2.1 Reporter: Cameron Fieber This is reproducable with the seam-space sample application: # Deploy seam-space on JBoss 5.0.0.GA # Sign up for a new account, and for username use an email address (user(a)host.net) # Sign out. # Sign in with the username and password with 'Remember Me' checked # Sign out. You should notice that the username that is autopopulated is only 'user' not 'user(a)host.net' I've tested it on both 2.1.1.CR1 and 2.1.1.GA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
7
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4161) Cookies stored incorrectly when web application is deployed with emty root path

by Evgeny Denisov (JIRA)

Cookies stored incorrectly when web application is deployed with emty root path -------------------------------------------------------------------------------- Key: JBSEAM-4161 URL: https://jira.jboss.org/jira/browse/JBSEAM-4161 Project: Seam Issue Type: Bug Components: Core, Security Affects Versions: 2.1.1.GA Environment: Firefox 3.0.x Reporter: Evgeny Denisov There is a bug in that prevents RememberMe functionality to work properly. This occurs when web application is deployed with empty context root path and can be reproduced in Firefox 3.0.8. There was similar bug reported earlier for Spring: http://jira.springframework.org/browse/SEC-364 The cause is empty cookie path that set to "" in org.jboss.seam.faces.Selector when context root of deployed web app is empty. An empty cookie path results in inconsistent behavior at least between ie and firefox: ie presumes "/" whereas firefox presumes the leading path for the current request. Chrome 1.0 also does not like empty cookie path. The bug can be fixed if method public void setCookiePath(String cookiePath) of org.jboss.seam.faces.Selector will be modified in the same way: public void setCookiePath(String cookiePath) { /* firefox does not like empty cookie path */ if (cookiePath == null || cookiePath.isEmpty()) { this.cookiePath = "/"; } else { this.cookiePath = cookiePath; } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3565) Remoting interface generation problem

by Andy Siu (JIRA)

Remoting interface generation problem ------------------------------------- Key: JBSEAM-3565 URL: https://jira.jboss.org/jira/browse/JBSEAM-3565 Project: Seam Issue Type: Bug Components: Remoting Reporter: Andy Siu Assignee: Shane Bryzak There is a problem about the caching mechanism of generating remote interface for ajax call. at public void generateComponentInterface(Set<Component> components, OutputStream out, Set<Type> types) The generated interface is cached in interfaceCache. However, when passing more than one component at the same time, there may be problem. E.g. seam/resource/remoting/interface.js?A&B where both A and B contain a type C A->C will be cached with the name A but only B will be cached with the name B (C will be skipped as it is already generated in A) when another page only calls seam/resource/remoting/interface.js?B C will be missed as the cached B does not contains C I've make a workaround by passing a new HashSet<Type>() into appendComponentSource everytime appendComponentSource(bOut, c, new HashSet<Type>()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields

by Lincoln Baxter III (JIRA)

Implement global protection against XSRF attacks via incremental token-based form fields ---------------------------------------------------------------------------------------- Key: SEAMFACES-26 URL: https://jira.jboss.org/browse/SEAMFACES-26 Project: Seam Faces Issue Type: Feature Request Components: Security Reporter: Lincoln Baxter III Fix For: 3.0.0.Alpha4 I'd like to see a way to implement this for ALL pages, not requiring a custom tag. I believe this could be done easily using the PreRenderViewEvent to add a hidden form field to store the token in all outbound forms, in combination with a cookie that is sent to the browser, storing a unique private key for that browser session. Next, use a phase-listener after Restore_View, comparing the request parameter to the restored component value or session. Very similar to the <s:token> component, but as a global solution that could be enabled/disabled via XML config. The token value increments on each subsequent form submission, and includes a hashed version of the browser's signature (and corresponding public key for the browser's cookie-assigned private key.) The token is compared to either a value stored in ViewState (insecure if using client-side state-saving) or a value stored in the user's session as (an ordered list that can detect repeat or invalid requests.) Question: how does this affect the back-button? Note: In order for any cookie-based public key to be assigned to the browser, one MUST assume that the server/client are speaking HTTPS, otherwise any communication of public/private keys will be vulnerable to man-in-the-middle attacks. "1. When rendered, it assigns a unique identifier to the browser using a cookie that lives until the end of the browser session. This is roughly the browser's private key. The <s:token> tag is used inside of an <h:form> and generates a hidden form field named javax.faces.FormSignature. The form signature is calculated as follows: " -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
10
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues June 2010