[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3972) identity login security bug
by David Croe (JIRA)
identity login security bug
---------------------------
Key: JBSEAM-3972
URL: https://jira.jboss.org/jira/browse/JBSEAM-3972
Project: Seam
Issue Type: Bug
Components: Security
Affects Versions: 2.1.1.GA
Environment: jboss 4.2.3.
Reporter: David Croe
Hello !
I think there is a major security bug in the seamspace example, which will give a user the permissions of the user which has been logged in before.
To reproduce the scenario:
1. login in as user demo.
2. click the back button or enter the login page manually in the url of your browser
3. login as another user.
the second user will have the admin permissions of the demo user!
Problem is that the authenticate method will not be invoked if you are allready logged in ( even as another user) and the old principal with the assigned permissions will stay in memory.
Greetings
D.Croe
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3941) IdentityMaanger: extend permission checks to allow user to modify his own password
by Raimund Hölle (JIRA)
IdentityMaanger: extend permission checks to allow user to modify his own password
----------------------------------------------------------------------------------
Key: JBSEAM-3941
URL: https://jira.jboss.org/jira/browse/JBSEAM-3941
Project: Seam
Issue Type: Feature Request
Components: Security
Affects Versions: 2.1.1.GA, 2.1.1.CR2, 2.1.1.CR1, 2.1.0.SP1
Reporter: Raimund Hölle
Priority: Minor
Because IdentityManager.changePassword() requires the permission ("seam.user", "update"), it is not possible to use that method to change the password of the authenticated user itself without granting that permission to him.
But granting that means, the user is able to modify _any_ user.
I'm suggest to add a new permission target (or maybe a new action) and extend the changePassword() method:
public static final String OWNPASSWORD_PERMISSION_NAME = "seam.user.ownpassword";
public boolean changePassword(String name, String password) {
Identity identity = Identity.instance();
try {
identity.checkPermission(USER_PERMISSION_NAME, PERMISSION_UPDATE);
} catch (AuthorizationException e) {
if ( identity.isLoggedIn() && identity.getCredentials().getUsername().equals(name) ) {
Identity.instance().checkPermission(OWNPASSWORD_PERMISSION_NAME, PERMISSION_UPDATE);
} else {
throw e;
}
}
return identityStore.changePassword(name, password);
}
Or maybe a specialized method?
Many regards,
Raimund
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2652) s:decorate does not respect prependId="false" on h:form
by Erik Magnusson (JIRA)
s:decorate does not respect prependId="false" on h:form
-------------------------------------------------------
Key: JBSEAM-2652
URL: http://jira.jboss.com/jira/browse/JBSEAM-2652
Project: JBoss Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.0.1.GA
Environment: JBoss Seam 2.0.1GA
Reporter: Erik Magnusson
Given the following code:
<h:form id="login" prependId="false">
<s:validateAll>
<f:facet name="afterInvalidField">
<s:label styleClass="error">
<s:message/>
</s:label>
</f:facet>
<div class="labelinputcombo ilcblock">
<h:outputLabel for="username">User name:</h:outputLabel>
<s:decorate>
<h:inputText id="username" value="#{registrationService.newUser.userName}" required="true"/>
</s:decorate>
</div>
</s:validateAll>
<div>
<h:commandButton value="Register" action="#{registrationService.registerUser}"/>
</div>
</h:form>
One would expect that none of the generated <input> elements would have prepended IDs, since the h:form has prependId="false". However, since s:decorate insists on inserting a superfluous <div> with a generated ID around the <input> elements it surrounds, those <input> elements end up having prepended IDs from that <div>. The relevant generated HTML:
<div class="labelinputcombo ilcblock">
<label for="j_id31:username">User name:</label><div id="j_id31"><input id="j_id31:username" type="text" name="j_id31:username" /></div>
</div>
I did not ask for either the <div> or it's ID (<div id="j_id31">), or its insertion into my <input> element's ID (id="j_id31:username").
Proposed solutions:
1. Remove the generated <div>. Is it really necessary for the functionality of s:decorate? If I want a div I can always add it myself.
2. If the <div> really is necessary, at least make s:decorate respect the prependId="false" attribute of the surrounding h:form.
3. If that is not possible, as a last resort, introduce a prependId attribute on the <s:decorate> tag so we can at least force this behaviour if we want it.
On a more general note,
I'm a really big fan of the JSF-Seam-EJB3 combo, but some of the design decisions in the frameworks are baffling. Why so many superfluous generated html tags? And who thought of the bright idea of prepending element id attributes using : (colon) as the delimeter?? This effectively cripples the ability to use CSS to style JSF-generated HTML elements with a simple CSS id selector (since : is a reserved symbol in CSS).
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2275) Document on Seam iText charting
by Joshua Partogi (JIRA)
Document on Seam iText charting
-------------------------------
Key: JBSEAM-2275
URL: http://jira.jboss.com/jira/browse/JBSEAM-2275
Project: JBoss Seam
Issue Type: Patch
Affects Versions: 2.0.0.GA
Environment: JBoss 4.2.1.GA
Reporter: Joshua Partogi
Fix For: 2.0.1.GA
Point 16.2
1. Write in doc to use the charting support, we need to add the jfreechart.jar and jcommon-*.jar in the project classpath. We can also add this is our build.xml
2. The key attribute is needed upon p:data component usage otherwise it will throw
this exception java.lang.IllegalArgumentException: Null 'key' argument.
at org.jfree.data.DefaultKeyedValues.setValue(DefaultKeyedValues.java:239)
at org.jfree.data.DefaultKeyedValues2D.setValue(DefaultKeyedValues2D.java:337)
at org.jfree.data.DefaultKeyedValues2D.addValue(DefaultKeyedValues2D.java:303).
In examples, it is used in (the ones below are the fixed value):
Barchart, Linechart, Series
PieChart
1. Attributes:
title — The chart title text.
legend — A boolean value indicating whether or not the chart should include a legend. Default value is true
is3D - A boolean value indicating that the chart should be rendered in 3D instead of 2D.
labelLinkMargin - The link margin
labelLinkPaint - The paint used for the label linking lines.
labelLinkStroke - The stroke used for the label linking lines.
labelLinksVisible - A flag that controls whether or not the label links are drawn.
labelOutlinePaint - The paint used to draw the outline of the section labels
labelOutlineStroke - The stroke used to draw the outline of the section labels
labelShadowPaint - The paint used to draw the shadow for the section labels
labelPaint - The color used to draw the section labels
labelGap - The gap between the labels and the plot as a percentage of the plot width.
labelBackgroundPaint - The color used to draw the background of the section labels. If this is null, the background is not filled.
startAngle - The starting angle
circular - A boolean value indicating whether whether to draw an ellipse or a perfect circle.
direction - The direction for the pie segments. If value is not set "anticlockwise" then by default it is clockwise.
sectionOutlinePaint - The outline paint for ALL sections (overrides list).
sectionOutlineStroke - The outline stroke for ALL sections (overrides list).
sectionOutlinesVisible - A flag that controls whether or not an outline is drawn for each section in the plot.
baseSectionOutlinePaint - The base section outline paint
baseSectionPaint - The base section paint
baseSectionOutlineStroke - The base section outline stroke
2. Usage:
<p:document xmlns:p="http://jboss.com/products/seam/pdf">
<p:piechart title="Pie Chart" circular="false" direction="anticlockwise"
startAngle="30" labelGap="0.1" labelLinkPaint="red">
<p:series key="Prices">
<p:data key="2003" columnKey="2003" value="7.36" />
<p:data key="2004" columnKey="2004" value="11.50" />
<p:data key="2005" columnKey="2005" value="34.625" />
<p:data key="2006" columnKey="2006" value="76.30" />
<p:data key="2007" columnKey="2007" value="85.05" />
</p:series>
</p:piechart>
</p:document>
--
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, 10 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3251) ValidateAllRendererBase not robust enough for dynamic components
by Richard Kennard (JIRA)
ValidateAllRendererBase not robust enough for dynamic components
----------------------------------------------------------------
Key: JBSEAM-3251
URL: https://jira.jboss.org/jira/browse/JBSEAM-3251
Project: Seam
Issue Type: Bug
Components: JSF Controls
Affects Versions: 2.1.0.A1, 2.0.3.CR1, 2.0.2.SP1
Environment: Any
Reporter: Richard Kennard
Priority: Minor
org.jboss.seam.ui.renderkit.ValidateAllRendererBase has two minor problems (with easy fixes) that stop it working with highly dynamic components:
1. doEncodeChildren attaches its ModelValidators before calling renderChildren. This misses any subcomponents the children may themselves dynamically create during their encodeBegin phase. Moving renderChildren down fixes this
2. A ModelValidator is only attached if the component has no existing Validators. This seems a bit of a blunt instrument. Presumably the idea is to stop attaching multiple ModelValidators. If the component happens to have, say, a LengthValidator that shouldn't stop ModelValidator entirely.
I have attached an updated ValidateAllRendererBase. It does not break any existing unit tests.
Disclaimer: my vested interest in this is because of Metawidget (http://www.metawidget.org).
--
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
14 years