Home » Modeling » EMF » [CDO] Set up security manager
|
Re: [CDO] Set up security manager [message #1004478 is a reply to message #1004469] |
Wed, 23 January 2013 10:21 |
|
Am 23.01.2013 10:59, schrieb Pierre Gaufillet:
> Hi!
>
> I am currently setting up a mock up based on CDO to demonstrate the capabilities of this great framework, and I am
> facing issues with the security manager. Using CDO explorer, I have created a /security resource with the following
> content :
>
> /Realm (Default Access: READ)
> |_User (ID: user01)
I think it should be possible to create an initial realm manually but it's proobably easier and maybe safer to let the
security manager do this in SecurityManager.createRealm().
> Then configured the server with: <securityManager type="default" realmPath="/security"/>
>
> It seems to start smoothly, but I am unable to log into the repository.
Because of what problem? What happens?
> Beyond this specific problem, I have a 2 related questions:
>
> - How to set up a password for users? It seems impossible through the tree editor. Does it need to be done using the API?
There's User.setPassword(UserPassword), which is the setter of a *containment reference* . It should be available in the
UI, too.
And there's SecurityManager.addUser(String, String):
public User addUser(final String id, final String password)
{
final User[] result = { null };
modify(new RealmOperation()
{
public void execute(Realm realm)
{
UserPassword userPassword = SecurityFactory.eINSTANCE.createUserPassword();
userPassword.setEncrypted(new String(password));
result[0] = realm.addUser(id);
result[0].setPassword(userPassword);
}
});
return result[0];
}
>
> - How to specify the EPackages for which you want to define permissions? When I add a Package Permission to Role, I
> don't see the registered EPackages in the list.
Good point! I think it's just an issue of the editor to fill the list properly. I wonder if we can mofidy the edit layer
of the security model. Can you please submit a respective enhancement request?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Re: [CDO] Set up security manager [message #1005359 is a reply to message #1005003] |
Fri, 25 January 2013 04:51 |
|
Am 24.01.2013 10:46, schrieb Pierre Gaufillet:
> Hi!
>
> I am facing an error when trying to switch to CDO framework from git master branch.
> On Linux x86_64, my target platform is based on Eclipse 4.3M4 and includes EMF SDK, EMF Compare and Net4j DB framework
If CDO comes from integration, i.e. a not-released version, then Net4j should be from the exact same origin. Better:
ensure that in general.
> Derby adapter (to get access to org.apache.derby).
You know that Derby is usually very slow compared to H2? That may be because of its stringent transactionality.
> The dependencies seems to be ok (something goes wrong in o.e.e.cdo.workspace.efs because I don't have org.h2 and
> org.h2.jdbcx installed, but I guess this is not used on the server side),
No.
> nevertheless the CDO server crashes at starting with error:
>
> [ERROR] java.sql.SQLSyntaxErrorException: Table/View 'CDO_PROPERTIES' does not exist.
>
> It happens systematically, even if the database doesn't exist and is to be initialized by the server. Any idea?
That reminds me to the PostgreSQL related bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=394213, which ought to be fixed.
Can you please try with H2 and see if the same problem occurs?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Re: [CDO] Set up security manager [message #1005481 is a reply to message #1005468] |
Fri, 25 January 2013 15:53 |
|
Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
> [quote title=Eike Stepper wrote on Wed, 23 January 2013 05:21]Am 23.01.2013 10:59, schrieb Pierre Gaufillet:
>> > - How to set up a password for users? It seems impossible through the tree editor. > > Does it need to be done using the API?
>> There's User.setPassword(UserPassword), which is the setter of a *containment reference* . It should be available in the
> UI, too.
>
> In fact, I still don't see a mean to change password in the UI :(
> right-clic on a user/new child give only a grayed "Password" item and Annotation.
Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set through
server API. It seems like a missing functionality, which is probably not too easy to design and implement such that it's
secure. Any thoughts on how this should appear to users/admins?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Set up security manager [message #1005482 is a reply to message #1005466] |
Fri, 25 January 2013 15:54 |
|
Am 25.01.2013 15:47, schrieb Pierre Gaufillet:
> [quote title=Eike Stepper wrote on Thu, 24 January 2013 23:51]Am 24.01.2013 10:46, schrieb Pierre Gaufillet:
>> You know that Derby is usually very slow compared to H2? That may be because of its stringent transactionality.
>
> No, I am far from being a DB expert :-/
> I have just chosen to use Derby because it was the default choice in exemplary cdo-server.xml. I just need a db with
> an easy set up for now.
Oops, how old is your cdo-server.xml?
We changed the default to H2, hmm, 3 or 4 years ago, IIRC...
>
>> > nevertheless the CDO server crashes at starting with error:
>> >
>> > [ERROR] java.sql.SQLSyntaxErrorException: Table/View 'CDO_PROPERTIES' does not exist.
>> >
>> > It happens systematically, even if the database doesn't exist and is to be initialized by the server. Any idea?
>> That reminds me to the PostgreSQL related bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=394213, which ought to be
>> fixed.
>>
>> Can you please try with H2 and see if the same problem occurs?
>
> You are right: it works correctly with H2. The overall CDO edition seems also far more stable. I am not anymore facing
> random exceptions when something goes wrong in the editor.
Excellent ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Set up security manager [message #1005722 is a reply to message #1005482] |
Mon, 28 January 2013 12:01 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
[quote title=Eike Stepper wrote on Fri, 25 January 2013 10:54]Am 25.01.2013 15:47, schrieb Pierre Gaufillet:
> > [quote title=Eike Stepper wrote on Thu, 24 January 2013 23:51]Am 24.01.2013 10:46, schrieb Pierre Gaufillet:
> >> You know that Derby is usually very slow compared to H2? That may be because of its stringent transactionality.
> >
> > No, I am far from being a DB expert :-/
> I have just chosen to use Derby because it was the default choice in exemplary cdo-server.xml. I just need a db with
> > an easy set up for now.
> Oops, how old is your cdo-server.xml?
>
> We changed the default to H2, hmm, 3 or 4 years ago, IIRC...
I followed the following tutorial to set up my initial cdo-server: wiki.eclipse.org/Setting_up_a_CDO_Server. It wasn't looking too old at first sight
|
|
|
Re: [CDO] Set up security manager [message #1005724 is a reply to message #1005481] |
Mon, 28 January 2013 12:09 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
[quote title=Eike Stepper wrote on Fri, 25 January 2013 10:53]Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
Eike Stepper wrote on Wed, 23 January 2013 05:21Am 23.01.2013 10:59, schrieb Pierre Gaufillet:
>> > - How to set up a password for users? It seems impossible through the tree editor. > > Does it need to be done using the API?
>> There's User.setPassword(UserPassword), which is the setter of a *containment reference* . It should be available in the
> UI, too.
>
> In fact, I still don't see a mean to change password in the UI
> right-clic on a user/new child give only a grayed "Password" item and Annotation.
Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set through
server API. It seems like a missing functionality, which is probably not too easy to design and implement such that it's
secure. Any thoughts on how this should appear to users/admins?
Well, Users may do this through an item in the menu of the CDO Sessions view, once logged in. Administrators would need to do it through the Realm editor, on the User object. This one should probably completely mask the default Password creation item.
In term of security, I guess it has already been solved in some way for the login stage of CDO sessions? The way password is to be transfered from client to server should be equivalent to it.
|
|
|
Re: [CDO] Set up security manager [message #1005757 is a reply to message #1005724] |
Mon, 28 January 2013 15:16 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
Eike,
your last commit has improved greatly the robustness and usability of the security manager. I have been able to test it further, and of course I have now a full new bunch of remarks and suggestions
- User default rights: in SecurityManager, I see:
protected CDOPermission getPermission(CDORevision revision, CDORevisionProvider revisionProvider,
CDOBranchPoint securityContext, User user)
{
CDOPermission result = convertPermission(user.getDefaultAccess());
if (result == CDOPermission.WRITE)
{
return result;
}
EList<Permission> allPermissions = user.getAllPermissions();
for (Permission permission : allPermissions)
{
CDOPermission p = convertPermission(permission.getAccess());
if (p.ordinal() <= result.ordinal())
...
if I understand correctly this code, it means that if the default access right for a given user is WRITE, then it replaces any other right that may have been defined elsewhere for this guy. It is disturbing, as most of the time default rights apply, well... when there is no other applicable right. I would therefore rather move this code to the end of the method and would not only return WRITE, but also READ and NONE access rights.
- ClassPermission.isApplicable() should take care of inheritance. When you give write access to ENamedElement for exemple, you expect that EClassifier will inherit this right. Strict application may nevertheless be an option.
- ClassPermission: it would be nice to have nested StructuralFeaturePermission allowing to refine access right in a given Class, with a default feature right access defined in the ClassPermission.
- Security / Server life cycle: it seems that modifications in the security resource are only reloaded when the server is restarted. If it is really so, it is really annoying: an action should be provided to reload it on demand, or changes should be automatically reloaded after they have been committed.
- CDO editor: "Create child" actions should be grayed (or optionally removed) when the user has no right to create them. Currently, it is possible to create objects in a resource even if you do not have the write access, but the modification are rejected in block at commit time: it is quite frustrating.
Of course, I would be pleased to submit tickets if you think it is appropriate.
Pierre
|
|
|
Re: [CDO] Set up security manager [message #1005793 is a reply to message #1005724] |
Mon, 28 January 2013 18:32 |
|
Am 28.01.2013 13:09, schrieb Pierre Gaufillet:
> [quote title=Eike Stepper wrote on Fri, 25 January 2013 10:53]Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
> Eike Stepper wrote on Wed, 23 January 2013 05:21
>> Am 23.01.2013 10:59, schrieb Pierre Gaufillet:
>> >> > - How to set up a password for users? It seems impossible through the tree editor. > > Does it need to be done
>> using the API?
>> >> There's User.setPassword(UserPassword), which is the setter of a *containment reference* . It should be available
>> in the > UI, too.
>> >
>> > In fact, I still don't see a mean to change password in the UI :(
>> > right-clic on a user/new child give only a grayed "Password" item and Annotation.
>> Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set
>> through server API. It seems like a missing functionality, which is probably not too easy to design and implement
>> such that it's secure. Any thoughts on how this should appear to users/admins?
>
>
> Well, Users may do this through an item in the menu of the CDO Sessions view, once logged in.
Good idea. Can you please submit an enhancement request?
> Administrators would need to do it through the Realm editor, on the User object.
It strikes me that Administrators should neither read user passwords nor set specific ones (that they would know then).
What about an action to just reset them to some newly generated one that is expected to be changed by the user later on?
> This one should probably completely mask the default Password creation item.
What do you mean by "mask"?
> In term of security, I guess it has already been solved in some way for the login stage of CDO sessions? The way
> password is to be transfered from client to server should be equivalent to it.
No, that's really different. There it's a Diffie-Hellman based challenge/response protocol that is initiated by the server.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Set up security manager [message #1005825 is a reply to message #1005793] |
Mon, 28 January 2013 20:58 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
[quote title=Eike Stepper wrote on Mon, 28 January 2013 13:32]Am 28.01.2013 13:09, schrieb Pierre Gaufillet:
Eike Stepper wrote on Fri, 25 January 2013 10:53Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
>> > In fact, I still don't see a mean to change password in the UI
>> > right-clic on a user/new child give only a grayed "Password" item and Annotation.
>> Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set
>> through server API. It seems like a missing functionality, which is probably not too easy to design and implement
>> such that it's secure. Any thoughts on how this should appear to users/admins?
>
>
> Well, Users may do this through an item in the menu of the CDO Sessions view, once logged in.
Good idea. Can you please submit an enhancement request?
Done in ticket #399306.
Quote:
> Administrators would need to do it through the Realm editor, on the User object.
It strikes me that Administrators should neither read user passwords nor set specific ones (that they would know then).
What about an action to just reset them to some newly generated one that is expected to be changed by the user later on?
And how do you transmit this new password to the user?
I think Administrators are to be trusted: I suggest therefore to keep a simple schema in this case. The only difference is that the Administrator can change any password without knowing the former one.
Quote:
> This one should probably completely mask the default Password creation item.
What do you mean by "mask"?
"Replace" would be better I guess.
|
|
|
Re: [CDO] Set up security manager [message #1005857 is a reply to message #1005825] |
Tue, 29 January 2013 05:59 |
|
Am 28.01.2013 21:58, schrieb Pierre Gaufillet:
> [quote title=Eike Stepper wrote on Mon, 28 January 2013 13:32]Am 28.01.2013 13:09, schrieb Pierre Gaufillet:
> Eike Stepper wrote on Fri, 25 January 2013 10:53
>> Am 25.01.2013 15:57, schrieb Pierre Gaufillet:
>> >> > In fact, I still don't see a mean to change password in the UI :(
>> >> > right-clic on a user/new child give only a grayed "Password" item and Annotation.
>> >> Ah, I remember now: I didn't do anything yet concerning the password management. I expected that these are set >>
>> through server API. It seems like a missing functionality, which is probably not too easy to design and implement >>
>> such that it's secure. Any thoughts on how this should appear to users/admins?
>> >
>> >
>> > Well, Users may do this through an item in the menu of the CDO Sessions view, once logged in. Good idea. Can you
>> please submit an enhancement request?
>
>
> Done in ticket https://bugs.eclipse.org/bugs/show_bug.cgi?id=399306.
Thx.
>
> Quote:
>> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that Administrators should neither read user passwords
>> nor set specific ones (that they would know then). What about an action to just reset them to some newly generated
>> one that is expected to be changed by the user later on?
>
>
> And how do you transmit this new password to the user? :)
That's a major challenge which I have no answer for at this point ;-(
> I think Administrators are to be trusted:
I have to totally disagree with this assertion. I wouldn't want an administrator to have access to my secure bank
account or credit card information. Or a hacker who compromised the admin password to have access to *all* user
passwords. I doubt that a linux root user can read user passwords and that should be a hint.
> I suggest therefore to keep a simple schema in this case.
As simple as adequate, but no simpler :P
> The only difference is that the Administrator can change any password without knowing the former one.
I think the most fundamental rule is: Noone (I repeat, noone!) except a user should have read access to this user's
password.
What brings us back to your first question: How is a new, random password that's been set by the admin (without actually
seeing or knowing it) made available to the user?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Set up security manager [message #1005943 is a reply to message #1005857] |
Tue, 29 January 2013 11:21 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
Eike Stepper wrote on Tue, 29 January 2013 00:59> Quote:
>> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that Administrators should neither read user passwords
>> nor set specific ones (that they would know then). What about an action to just reset them to some newly generated
>> one that is expected to be changed by the user later on?
>
>
> And how do you transmit this new password to the user?
That's a major challenge which I have no answer for at this point ;-(
> I think Administrators are to be trusted:
I have to totally disagree with this assertion. I wouldn't want an administrator to have access to my secure bank
account or credit card information. Or a hacker who compromised the admin password to have access to *all* user
passwords. I doubt that a linux root user can read user passwords and that should be a hint.
I am not talking about read access, but write access. Administrators may only be able to impose a new password, not read it. This is something any Unix admin can do (admin who by the way can take the identity of any user in the system without knowing their password ).
Alternatives are more complex. In the login dialog:
- Either propose sending a reinitialized password to the email address (or cellphone number) of the user (if known). The account is locked as long as this password has not been changed by the user. Inconvenient: you need to connect the CDO server to a SMTP server (or SMS service), and to have a known email address (or phone number).
- Or propose answering to some secret questions that have been previously defined by the user. If the answers are corrects, prompt for a new password. If not, rely on the method above.
But if none of these approach works, I am afraid we have to rely on a trusted third party :-/ In a lot of deployment cases, the first option won't be available.
Now, why not proposing several levels of security or mechanisms, depending on your requirements? It may be options of your cdo-server.xml or security realm?
Note that all this discussion also applies to the creation of CDO user accounts and privilege settings.
Pierre
|
|
|
Re: [CDO] Set up security manager [message #1005957 is a reply to message #1005943] |
Tue, 29 January 2013 12:04 |
|
Am 29.01.2013 12:21, schrieb Pierre Gaufillet:
> Eike Stepper wrote on Tue, 29 January 2013 00:59
>> > Quote:
>> >> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that
>> Administrators should neither read user passwords >> nor set specific ones (that they would know then). What about an
>> action to just reset them to some newly generated >> one that is expected to be changed by the user later on?
>> >
>> >
>> > And how do you transmit this new password to the user? :)
>> That's a major challenge which I have no answer for at this point ;-(
>>
>> > I think Administrators are to be trusted: I have to totally disagree with this assertion. I wouldn't want an
>> administrator to have access to my secure bank account or credit card information. Or a hacker who compromised the
>> admin password to have access to *all* user passwords. I doubt that a linux root user can read user passwords and
>> that should be a hint.
>
> I am not talking about read access, but write access. Administrators may only be able to impose a new password, not
> read it. This is something any Unix admin can do (admin who by the way can take the identity of any user in the system
> without knowing their password :) ).
That's an interesting point! It makes me aware that I have to rephrase my original assertion: If a password is set by a
user then noone else must be able to gain knowledge of it. The reason is obvious, that user might use it with other systems.
This opens the door for the following approach: Noone can read passwords (probably best to just store a hash of it). A
user can change it at any time, perhaps by repeating the old password again. An admin can change the password of any
user without repeating the old password of that user. It's the admin's responsibility to inform the user about the new
password and remind him to change it again as quickly as possible.
That may be what you had in mind ;-)
>
> Alternatives are more complex. In the login dialog:
>
> Either propose sending a reinitialized password to the email address (or cellphone number) of the user (if known). The
> account is locked as long as this password has not been changed by the user. Inconvenient: you need to connect the CDO
> server to a SMTP server (or SMS service), and to have a known email address (or phone number).
> Or propose answering to some secret questions that have been previously defined by the user. If the answers are
> corrects, prompt for a new password. If not, rely on the method above.
>
> But if none of these approach works, I am afraid we have to rely on a trusted third party :-/ In a lot of deployment
> cases, the first option won't be available.
>
> Now, why not proposing several levels of security or mechanisms, depending on your requirements? It may be options of
> your cdo-server.xml or security realm?
>
> Note that all this discussion also applies to the creation of CDO user accounts
Well, they're currently created by an admin or through server-side application code. So yes, the admin would also know
it for a while and would have to inform the user.
> and privilege settings.
How's that related?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Re: [CDO] Set up security manager [message #1005978 is a reply to message #1005957] |
Tue, 29 January 2013 13:07 |
Pierre Gaufillet Messages: 32 Registered: July 2009 |
Member |
|
|
Eike Stepper wrote on Tue, 29 January 2013 07:04Am 29.01.2013 12:21, schrieb Pierre Gaufillet:
> Eike Stepper wrote on Tue, 29 January 2013 00:59
>> > Quote:
>> >> > Administrators would need to do it through the Realm editor, on the User object. It strikes me that
>> Administrators should neither read user passwords >> nor set specific ones (that they would know then). What about an
>> action to just reset them to some newly generated >> one that is expected to be changed by the user later on?
>> >
>> >
>> > And how do you transmit this new password to the user?
>> That's a major challenge which I have no answer for at this point ;-(
>>
>> > I think Administrators are to be trusted: I have to totally disagree with this assertion. I wouldn't want an
>> administrator to have access to my secure bank account or credit card information. Or a hacker who compromised the
>> admin password to have access to *all* user passwords. I doubt that a linux root user can read user passwords and
>> that should be a hint.
>
> I am not talking about read access, but write access. Administrators may only be able to impose a new password, not
> read it. This is something any Unix admin can do (admin who by the way can take the identity of any user in the system
> without knowing their password ).
That's an interesting point! It makes me aware that I have to rephrase my original assertion: If a password is set by a
user then noone else must be able to gain knowledge of it. The reason is obvious, that user might use it with other systems.
This opens the door for the following approach: Noone can read passwords (probably best to just store a hash of it). A
user can change it at any time, perhaps by repeating the old password again. An admin can change the password of any
user without repeating the old password of that user. It's the admin's responsibility to inform the user about the new
password and remind him to change it again as quickly as possible.
That may be what you had in mind
You are right: that's it .
Quote:
> Note that all this discussion also applies to the creation of CDO user accounts
Well, they're currently created by an admin or through server-side application code. So yes, the admin would also know
it for a while and would have to inform the user.
...and taking into account the discussion above, this is perfectly acceptable.
Quote:
> and privilege settings.
How's that related?
You can forget about it for now: I was wondering what would happen if a user asks for a new account without the intervention of an administrator.
Pierre
|
|
| |
Re: [CDO] Set up security manager [message #1012781 is a reply to message #1012465] |
Fri, 22 February 2013 08:11 |
|
Am 21.02.2013 16:56, schrieb Marc Gil:
> Hi,
>
> I'm using CDO 4.2 M5 (S20130205-0640), and I'm having problems when use a created User. The problem appears when I
> start a session using a new created user, that doesn't have any password. An exception appears in the
> SessionManager$Authenticator class when try to get the password text from a non existent password element for this user.
>
> Concretelly in the line 605 of the SecurityManager class.
>
> java.lang.SecurityException: java.lang.NullPointerException
> at org.eclipse.emf.cdo.internal.server.SessionManager.authenticateUser(SessionManager.java:425)
> at org.eclipse.emf.cdo.internal.server.SessionManager.openSession(SessionManager.java:192)
> at org.eclipse.emf.cdo.server.internal.net4j.protocol.OpenSessionIndication.responding(OpenSessionIndication.java:125)
>
> If this is not solved, the only way to set a password is directly on the DB...
>
> In the case no password is set to the user, I think that a dialog should appear asking the new password for the user.
> With this, you can ensure first that the administrator doesn't set the password of the user, and the second that the
> user can login to the repository.
Pierre has written a nice tutorial on CDO's security model: http://wiki.eclipse.org/CDO/Security_Manager
Can you please check if your points do belong to any of the bugzillas he's already filed and possibly comment there?
Thanks;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] Set up security manager [message #1014614 is a reply to message #1012812] |
Tue, 26 February 2013 06:41 |
|
Am 22.02.2013 10:08, schrieb Marc Gil:
> Hi Eike!
>
> Yes, it's a very very nice tutorial from Pierre :d Because of this tutorial, I get finally to understand how to use
> the security in CDO :)
>
> I didn't check if exists any bug regarding this error, cause I assume that as the last message of this thread is dated
> at 29 January, and the CDO version I'm using is the last one available (the generated on 5 February), this problem is
> not really solved.
No, I didn't work in this area since.
> So maybe I should register a bugzilla, isn't it?
Yes, if you think it won't be a duplicate of one of Pierres' bugs.
> I have debugged the code and I found the error at the line 605 of the SecurityManager class, as I commented in my
> previous message.
Patches (on bugzillas) are highly appreciated ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Wed Sep 25 06:51:13 GMT 2024
Powered by FUDForum. Page generated in 0.11115 seconds
|