[jira] Resolved: (JCR-2904) Uncaught AbstractMethodError exception in in DomUtil.createFactory()
[ https://issues.apache.org/jira/browse/JCR-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-2904. Resolution: Fixed Fix Version/s: 2.2.5 Assignee: Jukka Zitting Thanks for the fix! I committed a slightly modified version in revision 1079314. Merged to the 2.2 branch in revision 1079315. Uncaught AbstractMethodError exception in in DomUtil.createFactory() Key: JCR-2904 URL: https://issues.apache.org/jira/browse/JCR-2904 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-webdav Affects Versions: 2.2.4 Environment: All Reporter: John Langley Assignee: Jukka Zitting Fix For: 2.2.5 Attachments: domUtil_patch.diff Original Estimate: 0.5h Remaining Estimate: 0.5h DomUtil.createFactory() throws an uncaught AbstractMethodError exception when xerces is on the classpath and the jackrabbit webdav module is used. This can render the class unusable when used in conjunction with the xerces library. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2904) Uncaught AbstractMethodError exception in in DomUtil.createFactory()
[ https://issues.apache.org/jira/browse/JCR-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003893#comment-13003893 ] Jukka Zitting commented on JCR-2904: Oops, my modifications were actually incorrect. I tried catching all Exceptions instead of just these two cases, but the other one was an Error so would not have been caught by my code. I revised the code to better match your original patch in revision 1079317 and merged it to 2.2 in revision 10709318. Uncaught AbstractMethodError exception in in DomUtil.createFactory() Key: JCR-2904 URL: https://issues.apache.org/jira/browse/JCR-2904 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-webdav Affects Versions: 2.2.4 Environment: All Reporter: John Langley Assignee: Jukka Zitting Fix For: 2.2.5 Attachments: domUtil_patch.diff Original Estimate: 0.5h Remaining Estimate: 0.5h DomUtil.createFactory() throws an uncaught AbstractMethodError exception when xerces is on the classpath and the jackrabbit webdav module is used. This can render the class unusable when used in conjunction with the xerces library. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-2910) Please add JackrabbitSession.isAdmin
Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003902#comment-13003902 ] Felix Meschberger commented on JCR-2910: I am not sure about such a method. This sounds like a utility method making it into the API which smells wrong. Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003915#comment-13003915 ] Jukka Zitting commented on JCR-2910: What's your use case for knowing whether the session is an admin session? Normally the admin status of a session should only be visible to a client as full access to all repository content. If we do need such a check for admin status, I'd rather implement it as something like session.checkPermission(/, admin) instead of introducing a new method for this. Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCRSITE-2) Add articles/tutorials page
[ https://issues.apache.org/jira/browse/JCRSITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003919#comment-13003919 ] Jukka Zitting commented on JCRSITE-2: - Added the articles page as suggested, thanks! The page should be online in a few hours. Add articles/tutorials page --- Key: JCRSITE-2 URL: https://issues.apache.org/jira/browse/JCRSITE-2 Project: Jackrabbit Site Issue Type: Improvement Components: site Reporter: Alexander Klimetschek Assignee: Alexander Klimetschek Attachments: Articles.txt, Navigation.txt Add articles page (copy from JcrLinks in the wiki), improve getting started page, change homepage to link to them See mailing list: http://markmail.org/message/allouxx4sbib35la -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003921#comment-13003921 ] Thomas Mueller commented on JCR-2910: - It's a security issue. Only admin users are allowed to backup the repository, or change the configuration using the GUI. I expect to use this method in quite a few places. Creating a utility method is possible of course, but it would just make things more complicated. something like session.checkPermission(/, admin) Which would be very ugly, don't you agree? SessionImpl.isAdmin() is already implemented, why make things more complicated than really necessary? If you like complicated, please explain *why*. Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003926#comment-13003926 ] Felix Meschberger commented on JCR-2910: What about JackrabbitSession.getUser()? Perfect. In addition this is orthogonal to Session.getUserID() Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003923#comment-13003923 ] Thomas Mueller commented on JCR-2910: - What about JackrabbitSession.getUser()? Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003931#comment-13003931 ] Dominique Pfister commented on JCR-2910: What about JackrabbitSession.getUser()? +1 Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003933#comment-13003933 ] Jukka Zitting commented on JCR-2910: casting to an implementation If your code works purely on the JCR API level, then the API should already enforce any access controls you need. Why do you then need the isAdmin() method? If you go below the JCR API, then you're already accessing implementation details and using SessionImpl.isAdmin() shouldn't be a problem. Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003935#comment-13003935 ] Thomas Mueller commented on JCR-2910: - The API we expose for these operations should simply throw exceptions if the user doesn't have enough access rights. That's exactly what I want to do. However, for this to implement, I need to know whether the current user has admin rights. Session.hasCapability() That's boolean Session.hasCapability(java.lang.String methodName, java.lang.Object target, java.lang.Object[] arguments) throws RepositoryException - which is even worse than Session.checkPermission(/, admin), well checkPermission isn't all that great because the second is a string property, and defined actions are add_node, set_property, remove, and read. As for the use case, I guess it's similar to find out if a Linux user is root. I would guess that's fairly easy in any API. If your code works purely on the JCR API level As I already wrote, I want to find out if the current logged in user is admin, because I want to backup the file system (just as an example). SessionImpl.isAdmin() shouldn't be a problem I repeat myself: it *is* a problem. One reason is that it doesn't work with virtual repositories. Casting to an implementation class is never really a good idea. So let's go for JackrabbitSession.getUser(). Please add JackrabbitSession.isAdmin Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2910) Please add JackrabbitSession.getUser()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-2910: Summary: Please add JackrabbitSession.getUser() (was: Please add JackrabbitSession.isAdmin) Please add JackrabbitSession.getUser() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-2910: Summary: Please add JackrabbitSession.isAdmin() (was: Please add JackrabbitSession.getUser()) Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003940#comment-13003940 ] Jukka Zitting commented on JCR-2910: backup the file system [...] doesn't work with virtual repositories So you want a backup feature that should both work with virtual repositories (that could be backed by anything), but still want to have the backup feature work on the file system level. I don't think that's a good idea. What we should do instead, is to have something like JackrabbitSession.backup (or RepositoryManager.backup) that takes care of all the required low-level functionality. Then a virtual repository can just decide whether it wants to direct the backup() call to just one main repository or try to combine the backups from multiple backend repositories. The Jackrabbit implementation of such a method would be in SessionImpl.backup(), where accessing the SessionImpl.isAdmin() method is no problem. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003942#comment-13003942 ] angela commented on JCR-2910: - What about JackrabbitSession.getUser()? while i would not object to move the SessionImpl.isAdmin to the API, that new suggestion doesn't make any sense to me. i added the former method recently to SessionImpl as we used to have plenty of duplicate code in jackrabbit-core that retrieved the subject from the session and tested if it contained a AdminPrincipal... thus SessionImpl.isAdmin basically doesn't rely on user management being implemented (in fact it is an optional feature that can be turned off by using a different security configuration). having this in mind Session#getUser really doesn't add any benefit over retrieving the User from the UserManager. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCRSITE-30) First Hops Update
[ https://issues.apache.org/jira/browse/JCRSITE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCRSITE-30. -- Resolution: Fixed Assignee: Jukka Zitting Thanks! I updated the web page and added the code under trunk/examples in revision 1079373. First Hops Update - Key: JCRSITE-30 URL: https://issues.apache.org/jira/browse/JCRSITE-30 Project: Jackrabbit Site Issue Type: Improvement Reporter: Alex Parvulescu Assignee: Jukka Zitting Priority: Trivial Attachments: First-Hops.txt, jackrabbit-firsthops.zip http://markmail.org/thread/7wz76hjmqojooobt Just another First Hops update to have the latest JR version. package the hops as a svn mini project -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003972#comment-13003972 ] Thomas Mueller commented on JCR-2910: - So you want a backup feature that should both work with virtual repositories No. But it might still be a virtual repository. Plus, as I already wrote, it's not just backup. There is a lot of code (most of it no my code) that needs this admin check, and it would be a lot of work to convert everything. From what I know, it's cluster configuration, data store garbage collection, index configuration, managing storage, managing workspaces, some diagnostic functions, data store import, some testing and profiling, some LDAP features. All those features currently check for admin rights in some way. Most of then either use getUserID().equals(admin) or cast to an implementation class. If you want to convert all that code, please feel free :-) SessionImpl.isAdmin OK, that means the following code wouldn't always work? (((User) js.getUserManager().getAuthorizable(session.getUserID())) Well, if the only reliable way is SessionImpl.isAdmin(), then let's add JackrabbitSession.isAdmin(). I agree with Felix, getUser() would be nice, and I don't understand how there could be no user. But JackrabbitSession.isAdmin() is OK as well. What is definitely *not* ok is: - casting to implementation, - or Session.getUserID().equals(admin), - or requiring to change a lot of code. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[
https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003987#comment-13003987
]
Jukka Zitting commented on JCR-2910:
a lot of code
That's not a good reason to introduce flawed design. The issue description
already outlines two workarounds that currently work with three or just one
line of code. They have similarly problems as the proposed isAdmin() method,
but at least they don't require changes to public API. As a longer term
solution we should get rid of such sloppy administration features and make them
proper parts of the repository implementation.
What I'm trying to avoid here is encouraging client code like this:
if (session.isAdmin()) {
doSomethingThatOnlyAdminsAreAllowedToDo();
}
It's too easy to accidentally or on purpose forget the isAdmin() call from
above, in which case you have an instant security issue.
The above code is perfectly fine within the implementation (and is also how our
normal access controls fundamentally work), but should not be used at the
client level. To borrow the Unix example, no Unix system allows a backup
program to access all system data just on the assumption that the program
should first check the geteuid() return value.
Please add JackrabbitSession.isAdmin()
--
Key: JCR-2910
URL: https://issues.apache.org/jira/browse/JCR-2910
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Priority: Minor
Currently finding out if the session user is an admin requires:
JackrabbitSession js = (JackrabbitSession) session;
User user = ((User) js.getUserManager().getAuthorizable(session.getUserID()));
boolean isAdmin = user.isAdmin();
Or: ((SessionImpl) session).isAdmin(). However casting to an implementation
is problematic for several reasons.
I think it would make sense to add isAdmin() to the JackrabbitSession
interface, so the code above would be:
((JackrabbitSession) session).isAdmin()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[
https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004015#comment-13004015
]
Thomas Mueller commented on JCR-2910:
-
flawed design
isAdmin() simply is not flawed design. Within Unix systems, there is a very
simple way to find out if the user is root.
encouraging client code... if (session.isAdmin()) {
So, basically you admit that the only reason for you to be against this feature
is to make my work harder? :-)
already outlines two workarounds
I already gave you the reasons why the workarounds are not acceptable.
Acceptable solutions are JackrabbitSession.getUser() (actually I would prefer
that), or JackrabbitSession.isAdmin(). I fail to see any reason why this would
be flawed design.
Please add JackrabbitSession.isAdmin()
--
Key: JCR-2910
URL: https://issues.apache.org/jira/browse/JCR-2910
Project: Jackrabbit Content Repository
Issue Type: Improvement
Reporter: Thomas Mueller
Priority: Minor
Currently finding out if the session user is an admin requires:
JackrabbitSession js = (JackrabbitSession) session;
User user = ((User) js.getUserManager().getAuthorizable(session.getUserID()));
boolean isAdmin = user.isAdmin();
Or: ((SessionImpl) session).isAdmin(). However casting to an implementation
is problematic for several reasons.
I think it would make sense to add isAdmin() to the JackrabbitSession
interface, so the code above would be:
((JackrabbitSession) session).isAdmin()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build became unstable: Jackrabbit-trunk » Jackrabbit JCR to WebDAV #1475
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-jcr2dav/1475/
Jenkins build became unstable: Jackrabbit-trunk #1475
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/1475/changes
Jenkins build became unstable: Jackrabbit-trunk » Jackrabbit Core #1475
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/1475/
Re: Jenkins build became unstable: Jackrabbit-trunk #1475
Hi, On 03/08/2011 06:02 PM, Apache Hudson Server wrote: Seehttps://hudson.apache.org/hudson/job/Jackrabbit-trunk/1475/changes Looks like a random failures (committed changes were in other areas): Test Result (3 failures / +3) org.apache.jackrabbit.core.state.DefaultISMLockingTest.testDowngrade org.apache.jackrabbit.core.state.DefaultISMLockingTest.testDowngrade org.apache.jackrabbit.jcr2spi.lock.SessionScopedLockTest.testCheckedInUnlock I don't remember seeing these before. Will investigate. -- Jukka Zitting
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004084#comment-13004084 ] Jukka Zitting commented on JCR-2910: Within Unix systems, there is a very simple way to find out if the user is root. That's just because Unix defines the special user id zero as root. The equivalent solution for us would be to define admin as the one and only administrator account. the only reason for you to be against this feature is to make my work harder? :-) :-) In the short term perhaps, but I strongly believe that a solution like the one proposed leads to more work in the long run. For example, what if we later decided to extend backup rights also to some special system account that only needs read access to everything but should never be able to write anything? This is fairly common in many environments, but would be impossible to implement if our backup tools relied on an isAdmin() method. However, a backup() API method could easily be modified to do this. Similarly, having administrative operations behind an API makes it possible to easily access that functionality through not just multiple different user interfaces (including JMX) but also from automated tests or things like scheduled backups. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004112#comment-13004112 ] Tobias Bocanegra commented on JCR-2910: --- i agree with jukka. Session.isAdmin() is not the correct way to enforce security since it's not extendable. basically, all resources and services need to be subject to access control. i'd rather add the respective policies like (rep:backup) and check against them than a vague isAdmin() check. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JCR-2904 and jr 2.2.5
Hi, On 03/07/2011 04:05 PM, John Langley wrote: Any notion whether JCR-2904 will make it into 2.2.5? I committed the fix and merged it to the 2.2 branch so it'll be included in the 2.2.5 release. I planned to cut 2.2.5 already some while ago, but never got around to doing that. I hope to get it done tomorrow. -- Jukka Zitting
Re: somewhat off topic
Hi, On 03/07/2011 02:01 PM, John Langley wrote: How often is the jira webserver down? It seems that it is often inaccessible in the morning us east coast time. Is it just me? Are there alternative urls? Where should I address the issues concerns? The Jira instance at Apache is quite heavily used and sometimes a bit slow, but I haven't seen it become totally unavailable except for a few special cases. If you have repeated problems, infrastruct...@apache.org is the best place to contact about them. The more details (your IP address, the times you try to access Jira, the exact response you're getting, etc.) you can provide the better. -- Jukka Zitting
Jenkins build is back to stable : Jackrabbit-trunk » Jackrabbit JCR to WebDAV #1476
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-jcr2dav/1476/
Jenkins build is back to stable : Jackrabbit-trunk » Jackrabbit Core #1476
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/1476/
Jenkins build is back to stable : Jackrabbit-trunk #1476
See https://hudson.apache.org/hudson/job/Jackrabbit-trunk/1476/
Re: somewhat off topic
Thanks will do. On Tue, Mar 8, 2011 at 1:34 PM, Jukka Zitting jzitt...@adobe.com wrote: Hi, On 03/07/2011 02:01 PM, John Langley wrote: How often is the jira webserver down? It seems that it is often inaccessible in the morning us east coast time. Is it just me? Are there alternative urls? Where should I address the issues concerns? The Jira instance at Apache is quite heavily used and sometimes a bit slow, but I haven't seen it become totally unavailable except for a few special cases. If you have repeated problems, infrastruct...@apache.org is the best place to contact about them. The more details (your IP address, the times you try to access Jira, the exact response you're getting, etc.) you can provide the better. -- Jukka Zitting
Re: JCR-2904 and jr 2.2.5
Excellent, THANK YOU! -- Langley On Tue, Mar 8, 2011 at 1:31 PM, Jukka Zitting jzitt...@adobe.com wrote: Hi, On 03/07/2011 04:05 PM, John Langley wrote: Any notion whether JCR-2904 will make it into 2.2.5? I committed the fix and merged it to the 2.2 branch so it'll be included in the 2.2.5 release. I planned to cut 2.2.5 already some while ago, but never got around to doing that. I hope to get it done tomorrow. -- Jukka Zitting
[jira] Commented: (JCR-2910) Please add JackrabbitSession.isAdmin()
[ https://issues.apache.org/jira/browse/JCR-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004208#comment-13004208 ] Alexander Klimetschek commented on JCR-2910: I agree with Jukka Tobi. isAdmin() is too much authentication only (just a user identification) and not much of an authorization privilege (only a very generic one, playing god). But the use case clearly is focused around authorization, and might need new privileges as the right solution. Please add JackrabbitSession.isAdmin() -- Key: JCR-2910 URL: https://issues.apache.org/jira/browse/JCR-2910 Project: Jackrabbit Content Repository Issue Type: Improvement Reporter: Thomas Mueller Priority: Minor Currently finding out if the session user is an admin requires: JackrabbitSession js = (JackrabbitSession) session; User user = ((User) js.getUserManager().getAuthorizable(session.getUserID())); boolean isAdmin = user.isAdmin(); Or: ((SessionImpl) session).isAdmin(). However casting to an implementation is problematic for several reasons. I think it would make sense to add isAdmin() to the JackrabbitSession interface, so the code above would be: ((JackrabbitSession) session).isAdmin() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (JCR-2911) Fine-grained access control for managing node types
Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Fix For: 2.3.0 Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2911) Fine-grained access control for managing node types
[ https://issues.apache.org/jira/browse/JCR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omid Milani updated JCR-2911: - Status: Patch Available (was: Open) Added a accessManagerForNodeTypes interface. When repository accessManager implements that interface too, nodeTypeManagerImpl will ask it for permission for register/unregister of node types. Also noticed that nodeTypeManagerImpl.getNodeTypeRegistry is public, which seems wrong. Made it protected, and changed it's uses to sessionContext.getNodeTypeRegistry (which was available everywhere but in one unit test) I've tested this only as part of my system and haven't added unit tests here. Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Labels: accessManager, nodetype, security Fix For: 2.3.0 Original Estimate: 5m Remaining Estimate: 5m Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2911) Fine-grained access control for managing node types
[ https://issues.apache.org/jira/browse/JCR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omid Milani updated JCR-2911: - Attachment: accessManager_nodeTypes.patch description in earlier comment Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Labels: accessManager, nodetype, security Fix For: 2.3.0 Attachments: accessManager_nodeTypes.patch Original Estimate: 5m Remaining Estimate: 5m Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2911) Fine-grained access control for managing node types
[ https://issues.apache.org/jira/browse/JCR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Omid Milani updated JCR-2911: - Resolution: Fixed Status: Resolved (was: Patch Available) Have added the patch. Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Labels: accessManager, nodetype, security Fix For: 2.3.0 Attachments: accessManager_nodeTypes.patch Original Estimate: 5m Remaining Estimate: 5m Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2911) Fine-grained access control for managing node types
[ https://issues.apache.org/jira/browse/JCR-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004396#comment-13004396 ] Felix Meschberger commented on JCR-2911: Shouldn't node type definition authorization be defined by access control on the node type definition storage (/jcr:system/jcr:nodeTypes) ? Fine-grained access control for managing node types --- Key: JCR-2911 URL: https://issues.apache.org/jira/browse/JCR-2911 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core, nodetype Affects Versions: 2.2.4, 2.3.0 Reporter: Omid Milani Priority: Minor Labels: accessManager, nodetype, security Fix For: 2.3.0 Attachments: accessManager_nodeTypes.patch Original Estimate: 5m Remaining Estimate: 5m Extend AccessManager interface to include authorization for register/unregister of node types so it can be defined that a certain user can define and modify some node types but not the others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
