[magnolia-dev] [JIRA] (MGNLFORUM-270) DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
Cheng Hu updated MGNLFORUM-270 DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups Change By: Cheng Hu (12/Aug/14 5:02 AM) Labels: maintenance next support This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLCACHE-32) Upgrade ehcache
Grégory Joseph updated MGNLCACHE-32 Upgrade ehcache Change By: Grégory Joseph (11/Aug/14 6:58 PM) Labels: architecture support This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLCACHE-67) Verify cache persistence after upgrade to ehcache 2.8
Grégory Joseph created MGNLCACHE-67 Verify cache persistence after upgrade to ehcache 2.8 Issue Type: Sub-task Assignee: Unassigned Created: 11/Aug/14 7:01 PM Description: It would appear that since ehcache 2.6, caches aren't persisted after a restart. I'm pretty sure I tested for this, but the documentation tells me differently: http://ehcache.org/documentation/configuration/fast-restart It should be doable to verify this with a unit test, provided that ehcache doesn't keep stuff in memory after we explicitly shut it down. Fix Versions: 5.3 Project: Magnolia Cache Module Priority: Neutral Reporter: Grégory Joseph This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3093) Improve UI for deleting folders, groups or roles which are still in use
Mikaël Geljic
updated MGNLUI-3093
Improve UI for deleting folders, groups or roles which are still in use
Change By:
Mikaël Geljic
(11/Aug/14 5:53 PM)
Issue Type:
Bug
Improvement
Labels:
ux
Assignee:
Evzen Fochr
Attachment:
MGNLUI-3062-folder.png
Attachment:
MGNLUI-3062-role.png
Fix Version/s:
5.2.x
Fix Version/s:
5.3.x
Fix Version/s:
5.3.3
Fix Version/s:
5.2.9
Reporter:
Karel de Witte
Mikaël Geljic
Affects Version/s:
5.2.9
Affects Version/s:
5.3.2
Affects Version/s:
5.3.1
Priority:
Major
Neutral
Description:
Go to Security
Solution implemented with MGNLUI
-
> Groups
3062 "does the job" in preventing and notifying when trying to delete folders with groups/roles that are still in use, but it hasn't quite met the UI requirements, in particular:
1. Select non empty folder
2
- This is not an alert, but a notification
.
"Delete Folder"
Alerts have an [ OK ] button.
3
- This is not of level WARNING (yellow) but ERROR (red)
.
Confirmation dialog: "
- When folder is not empty, I should get the alert as soon as I click '
Delete
this
folder
? The folder and all its sub
' in the action bar, not after the confirmation.
-
items will be marked
Wording is not as specified in the comment. Please also use separate keys
for
deletion
roles VS
.
"
groups.
4
Original specification comment:{quote}For single groups (resp
.
Press "YES -
roles), if I attempt to
delete
a group which is still in use, I get a warning alert:
"
This group still contains users. Please empty the group first. [ OK ]"
5
Likewise for group folders (resp
.
Error: Deletion has failed
role folders)
.
/wcmstestkopie
I get a warning alert
:
info
"This folder contains groups which are still in use
.
magnolia
Please make sure no users are assigned to these first
.
ui
[ OK ]"If the folder contains only unused items, then we get the confirmation dialog as usual
.
api.action.ActionExecutionException: Folder is not empty
{quote}
Please see MGNLUI-2635
Meanwhile, current implementation has the advantage of showing details as to which assignment is currently preventing deletion.We should think about how we want to display these details, both in terms of what can be done right now,
and
SUPPORT-3049
what should be done in the future.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details, see: http://www.magnolia-cms.c
[magnolia-dev] [JIRA] (MGNLUI-3093) Improve UI for deleting folders, groups or roles which are still in use
Federico Grilli updated MGNLUI-3093 Improve UI for deleting folders, groups or roles which are still in use Change By: Federico Grilli (11/Aug/14 5:37 PM) Fix Version/s: 5.3.3 Fix Version/s: 5.3.2 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLFORUM-270) DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
Christian Ringele
created MGNLFORUM-270
DefaultForumManager#isModerator() checks only the directly attached roles of the user, but ignores his roles inherited from his groups
Issue Type:
Bug
Affects Versions:
3.4.1, 3.3.3
Assignee:
Unassigned
Attachments:
DefaultForumManager.patch
Components:
moderation
Created:
11/Aug/14 5:20 PM
Description:
When trying to edit a form message, not only the ACL is checked, but also the method isModerator() is called on the DefaultForumManager.
This method only checks if the user has the roles "forum_ALL-admin" and "forum_ALL-moderator" directly assigned to the user. (currentUser.hasRole()).
But it is not checking, if the user has this role "inherited" be a group he is part of.
This means, if you have the role "forum_ALL-admin" only as a role of a group, you won't be able to edit a message, even if you have the content access rights to the data.
This is a big problem for all AD/LDap users. As AD/LDap users are matched by their user name or user group, one can not directly assign a role to a ad user, only groups. So even if the logged in AD user has the role by one if its group, he can not edit a message.
Former code:
@Override
public void isModerator() throws AccessDeniedException{
User currentUser = MgnlContext.getUser();
if (!currentUser.hasRole(ROLE_FORUM_ALL_MODERATOR) && !currentUser.hasRole(ROLE_FORUM_ALL_ADMIN)) {
throw new AccessDeniedException("User not allowed to perform that action.");
}
}
Should be changed to:
@Override
public void isModerator() throws AccessDeniedException{
User currentUser = MgnlContext.getUser();
boolean hasRole = false;
// Needs to use getAllRoles() instead of .hasRole() because .hasRole() will only check for the roles directly attached to the user, but not the ones inherited from the group.
// As roles can not directly be attached to a AD user, it is crucial to be able to define it over its group.
Collection allRoles = currentUser.getAllRoles();
for (Iterator iterator = allRoles.iterator(); iterator.hasNext();) {
String roleName = iterator.next();
if (roleName.equals(ROLE_FORUM_ALL_MODERATOR) || roleName.equals(ROLE_FORUM_ALL_ADMIN)) {
hasRole = true;
}
}
if (!hasRole) {
throw new AccessDeniedException("User not allowed to perform that action.");
}
}
The "currentUser.getAllRoles();" returns all roles also the ones form the user's groups.
I added the patch of the class.
But tests are failing because the mock user returns a empty list on .getAllRoles();
Test should be fixed accordingly.
Project:
Magnolia Forum Module
Labels:
support
Priority:
Critical
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3093) Improve UI for deleting folders, groups or roles which are still in use
Karel de Witte created MGNLUI-3093 Improve UI for deleting folders, groups or roles which are still in use Issue Type: Bug Affects Versions: 5.3.1 Assignee: Evzen Fochr Components: security app Created: 11/Aug/14 4:29 PM Description: Go to Security -> Groups 1. Select non empty folder 2. "Delete Folder" 3. Confirmation dialog: "Delete this folder? The folder and all its sub-items will be marked for deletion." 4. Press "YES - delete" 5. Error: Deletion has failed. /wcmstestkopie: info.magnolia.ui.api.action.ActionExecutionException: Folder is not empty Please see MGNLUI-2635 and SUPPORT-3049 Fix Versions: 5.2.9, 5.3.2 Project: Magnolia UI Priority: Major Reporter: Karel de Witte This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and rething XSS impl in Forum module.
Christian Ringele created MGNLUI-3092 Consider XSS atacks in AdminCentral and rething XSS impl in Forum module. Issue Type: Improvement Assignee: Unassigned Components: forms Created: 11/Aug/14 2:09 PM Description: A customer who looked deep into the Form module validation and field value submission rose this topic (SUPPORT-3873): 1. As for preventing XSS attacks in the form module all inputs are html escaped, a similar approach should also be considered within the AdminCentral forms. In the AdminCentral all form fields are open to XSS attacks. It would be favorable, it the used solution would be aligned/comparable to the (new) implementation used in the form module. 2. Which leads to the second points: He suggests to rethink the XSS html escaping implementation currently used in the form module. It might not be the best way to prevent such attacks. As this topic is involving two modules, I created it here in the UI section (point 1 seems more important). Project: Magnolia UI Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and re-think XSS impl in Forum module.
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and re-think XSS impl in Forum module. Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: Consider XSS atacks in AdminCentral and rethink re-think XSS impl in Forum module. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and re-think XSS impl in Form modulet
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and re-think XSS impl in Form modulet Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: Consider XSS atacks in AdminCentral and re-think XSS impl in Forum module. Form modulet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS atacks in AdminCentral and rethink XSS impl in Forum module.
Christian Ringele updated MGNLUI-3092 Consider XSS atacks in AdminCentral and rethink XSS impl in Forum module. Change By: Christian Ringele (11/Aug/14 2:09 PM) Summary: Consider XSS atacks in AdminCentral and rething rethink XSS impl in Forum module. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS attacks in AdminCentral and re-think XSS impl in Form modulet
Christian Ringele updated MGNLUI-3092 Consider XSS attacks in AdminCentral and re-think XSS impl in Form modulet Change By: Christian Ringele (11/Aug/14 2:10 PM) Summary: Consider XSS atacks attacks in AdminCentral and re-think XSS impl in Form modulet This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLUI-3092) Consider XSS attacks in AdminCentral and re-think XSS impl in Form module
Christian Ringele updated MGNLUI-3092 Consider XSS attacks in AdminCentral and re-think XSS impl in Form module Change By: Christian Ringele (11/Aug/14 2:10 PM) Summary: Consider XSS attacks in AdminCentral and re-think XSS impl in Form modulet module This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLPUR-138) TokenPasswordProcessor does not check if the user has an actual token
Christian Ringele
created MGNLPUR-138
TokenPasswordProcessor does not check if the user has an actual token
Issue Type:
Bug
Affects Versions:
2.3.1
Assignee:
Unassigned
Created:
11/Aug/14 2:01 PM
Description:
No check is done to see if the user actually has a token. If the user has no token (e.g. because the password change functionality has already been used; e.g. the user clicks on the change password link twice) you get an ugly null pointer. We added this in our TokenPasswordProcessor. See code below.
The error messages (which are shown to the end-user) are hardcoded. i18n messages should really be used.
I think it would be good to add this to the Magnolia TokenPasswordProcessor class?
// not present in Magnolia's TokenPasswordProcessor
// check if user's token is present at all; if we don't do this and the token is not present
// we get an ugly nullpointer later on
if (null == user.getProperty("token")) {
throw new FormProcessorFailedException("No 'password change token' is present in the current user session. " +
"Maybe you have already changed your password? Should you want to change your password again then please " +
"request a new password reset.");
}
Project:
Magnolia Public User Registration
Labels:
support
Priority:
Neutral
Reporter:
Christian Ringele
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLFORM-236) Html Escaping of form fields should be configurable
Christian Ringele
updated MGNLFORM-236
Html Escaping of form fields should be configurable
Change By:
Christian Ringele
(11/Aug/14 1:57 PM)
Description:
The form module html escapes by default inputs. This is in certain situations not good.Clearly in the password field, as it won't store the PW with allowed characters different than the 1:1 input. This leads to problems when reusing the PW also for other systems.Also the customer needs to store from other fields inputs which are unchanged (see linked support ticket). Examples as original value to store {code}Research & Development{code} becomes {code}Research & Development{code}
.
The problem is this line in the info.magnolia.module.form.templates.components.DefaultFormDataBinder#bindAndValidateFields method:{code}final String value = EscapeUtil.escapeXss(StringUtils.join(MgnlContext.getParameterValues(controlName), "__"));{code}Suggested solution:All form fields should be html escaped to prevent XSS attacks.But allow a configuration on the form field to disable it for this specific field.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLFORM-236) Html Escaping of form fields should be configurable
Christian Ringele created MGNLFORM-236 Html Escaping of form fields should be configurable Issue Type: Improvement Affects Versions: 2.2.5 Assignee: Unassigned Created: 11/Aug/14 1:56 PM Description: The form module html escapes by default inputs. This is in certain situations not good. Clearly in the password field, as it won't store the PW with allowed characters different than the 1:1 input. This leads to problems when reusing the PW also for other systems. Also the customer needs to store from other fields inputs which are unchanged (see linked support ticket). Examples as original value to store Research & Development becomes Research & Development . The problem is this line in the info.magnolia.module.form.templates.components.DefaultFormDataBinder#bindAndValidateFields method: final String value = EscapeUtil.escapeXss(StringUtils.join(MgnlContext.getParameterValues(controlName), "__")); Suggested solution: All form fields should be html escaped to prevent XSS attacks. But allow a configuration on the form field to disable it for this specific field. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (VANITY-7) Label for delete confirm dialog not set
Frank Sommer created VANITY-7 Label for delete confirm dialog not set Issue Type: Bug Affects Versions: 1.2.0 Assignee: Frank Sommer Created: 11/Aug/14 12:33 PM Description: The various labels for the delete confirm dialog don't exist. Fix Versions: 1.2.1 Project: Vanity URL app Priority: Neutral Reporter: Frank Sommer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLFORM-235) Field, allow using more than one validator: The relation between a form field and a validator should be 1:n and not 1:1.
Christian Ringele created MGNLFORM-235 Field, allow using more than one validator: The relation between a form field and a validator should be 1:n and not 1:1. Issue Type: Improvement Affects Versions: 2.2.5 Assignee: Unassigned Components: field Created: 11/Aug/14 12:15 PM Description: In a form field one can choose only one validator to use (one drop down). This means that if you use 2-3 validators in your project very often, one must encapsulate its logic into a single one, even all three are existing with their perfect logic. An example: Regexp validator with general check for all fields. Password validator for the password field. Solution: A multifield value should be used to allow choosing a 1:n relation. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (BUILD-130) Upgrade to Maven 3.x
Grégory Joseph updated BUILD-130 Upgrade to Maven 3.x Change By: Grégory Joseph (11/Aug/14 10:25 AM) Labels: maven maven3 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLFORM-234) ValidateExpression should not extend NoHTMLValidator, as it prohobits valid password characters
Christian Ringele created MGNLFORM-234 ValidateExpression should not extend NoHTMLValidator, as it prohobits valid password characters Issue Type: Bug Affects Versions: 2.2.5 Assignee: Unassigned Components: validation Created: 11/Aug/14 9:56 AM Description: The regexp based validator: info.magnolia.module.form.validators.ValidateExpression extends the class: info.magnolia.module.form.validators.NoHTMLValidator Using the NoHTMLValidator as a base class for all other fields makes sense, as it prohibuts html characters in form fields. But the NoHTMLValidator prohibits characters which are perfectly fine as password characters. So the ValidateExpression should extends directly the base class Validator, and if by default it still should constrain by the html characters, it should directly be added to the used _expression_ itself. So its obvious and easy changeable. Project: Magnolia Form Module Labels: support Priority: Neutral Reporter: Christian Ringele This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
[magnolia-dev] [JIRA] (MGNLDATA-262) Remaining activate/deactive commands after 4.5 upgrade
Mikaël Geljic updated MGNLDATA-262 Remaining activate/deactive commands after 4.5 upgrade Change By: Mikaël Geljic (11/Aug/14 9:22 AM) Attachment: data-ee-diff.png This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to:
