[openjms-developer] RE: Admin API and GUI

[Tim Anderson]

Thanks Knut.

I'll commit the changes but I think the new admininistration API needs to be
thought out more.
We can safely deprecate the existing admin API - you're effectively working
with a clean slate so you don't need to be tied to the existing method
implementations. If need be, we can also add new JMSException subclasses
to indicate the reasons for failures. Some of the existing methods
confusingly
throw JMSException but also return a boolean status.

In particular, I don't see the advantage in separating the JmsAdminServerIfc
into AdminConnection, MonitorConnection and SystemConnection.

I would prefer AdminConnection to be the main interface - this would
provide access to destination, security, and server management objects.

E.g:
AdminConnectionFactory - create an AdminConnection.
AdminConnection - provides access to Destinations, Security, and Server
objects.
Destinations - topic and queue management.
Server - server management. Probably only a single method
for the moment, i.e shutdown()
Security - user, and in future, ACL management

Also, it would be nice if in future the code you submit followed coding
conventions ;)
I'm aiming to have the maven build env complete in a week or so - one of the
nice
things it does is include checkstyle reports, so its easy to see what needs
to be
changed.

Regards,

Tim

-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 3:14 AM
To: ***@netspace.net.au
Subject: Admin API and GUI


All src. is based on the latest version from the CVS.

Have made only minimum requirement on the GUI since Im going to rewrite
this during this autumn.
Have not impl. Logon for offlineConnection


Classes that have changed name;

AdminConnection --> AbstractAdminConnection -- needed the
AdminConnection for the new connection-interface
OpenJMSDestination --> OpenJMSObject -- needed this for OpenJMSUser as
well, thought the name was a bit misleading.

New classes;
CreateLogonDialog
CreateUserDialog
ChangePasswordDialog
OpenJMSUser
OpenJMSObject <--- replace OpenJMSDestination
AbstractAdminConnection <--- replace AdminConnection

I have rewritten how to obtain administred connections:
classes;
ConnectionFactory

interfaces:
Connect <--- contains only connect() and disconnect() is
package-private.
AdminConnection <---
---- Replaces the old
JmsAdminServerIfc
MonitorConnection <---
SystemConnection <--- Not impl. to be used to configure the server:
cache, log, acceptors etc.

Have deprecated JmsAdminServerIfc and AdminConnectionFactory


Modified classes;
see Zip-file.
Have been trying to run a diff against the cvs but the operation gets
canceled evry time so Im afraid you will have to do that .....


K

[Tim Anderson]

See inline
-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 6:56 PM
To: ***@netspace.net.au
Subject: Re: Admin API and GUI



----- Original Message -----
From: Tim Anderson
To: openjms-developer ; Knut at work
Sent: Tuesday, July 29, 2003 4:26 AM
Subject: RE: Admin API and GUI


Thanks Knut.

I'll commit the changes but I think the new admininistration API needs
to be
thought out more.
We can safely deprecate the existing admin API - you're effectively
working
with a clean slate so you don't need to be tied to the existing method
implementations. If need be, we can also add new JMSException subclasses
to indicate the reasons for failures. Some of the existing methods
confusingly
throw JMSException but also return a boolean status.

Some of the methods should not throw JMSException at all! User for
instance.
What about a own exception eg. AdminException??
[tima] Yep - thats fine. The advantage of subclassing JMSException is
that
you don't have too many throw clauses which make the API
unwieldy to use.
It just encourages people to catch Exception instead.

Also connect() disconnect() - connect() need to be able to throw
JMSSecurityEx
but all other exeptions have somthing to do with the connection not JMS.

[tima] I would drop the Connect interface. AdminConnectionFactory would
then
change to

public class AdminConnectionFactory {

public AdminConnection connect(String url, String username, String
password)
throws JMSSecurityException, AdminException;

/**
*
* @deprecated
*/
public JmsAdminServerIfc create(String url) .....
}


Im not very found of boolean statuses for methods doing
add/change/remove
I prefer either void or that they return the Object the are working
with.
All other 'returns' are Exceptions eg. add of a duplicate object is a
Exception not a false.

In particular, I don't see the advantage in separating the
JmsAdminServerIfc
into AdminConnection, MonitorConnection and SystemConnection.

My intention behind this was to separate according to Acl.
To be able to use Admin you must be eg. Administrator
To be able to use MonitorConnection (only read access) it is mabe enough
to have AdminReadOnly.....
Also I find it possible to e.g. write a stand alone appl. to monitor the
system.
[tima] This can be handled within the AdminConnection itself. If a user
attempts to
access an object they are not authorised to use, it would
throw JMSSecurityException.

I would prefer AdminConnection to be the main interface - this would
provide access to destination, security, and server management objects.

E.g:
AdminConnectionFactory - create an AdminConnection.
AdminConnection - provides access to Destinations, Security, and
Server
objects.
Destinations - topic and queue management.

Server - server management. Probably only a single
method
for the moment, i.e shutdown()
This Is this equal to what I called SystemConnection so we agree on
this.

Security - user, and in future, ACL management

I agree on the separation in Destination/Security when it comes to how
to build the GUI.
But as a Interface this looks like subinterfaces of what I called
AdminConnection.
Reason: Needs the same accesslevel and I likely the user will need both
interfaces in
the same application.
[tima] With the separation you are proposing, an application potentially
needs to
establish three authenticated connections to the server, to
perform administration
functions. The alternative approach above only requires single
sign on,
with the expectation that future ACL management will prevent
unauthorised
operations.

Also, it would be nice if in future the code you submit followed coding
conventions ;)

Of course, but where do I find the conventions??
[tima] Good point. I removed them with the expectation I would have the
maven build
up and running by now - as no-one ever reads coding convention
docs,
its must easier if the build process reports on violations.
Maven runs checkstyle as part of its report generation process.
You can see the current results here:
http://openjms.sourceforge.net/checkstyle-report.html
As you can see, there's a lot of cleaning up to do. My aim is
to not
introduce new violations, and gradually clean up the existing
ones.

I'm aiming to have the maven build env complete in a week or so - one of
the nice
things it does is include checkstyle reports, so its easy to see what
needs to be
changed.

Regards,

Tim


-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 3:14 AM
To: ***@netspace.net.au
Subject: Admin API and GUI


All src. is based on the latest version from the CVS.

Have made only minimum requirement on the GUI since Im going to
rewrite this during this autumn.
Have not impl. Logon for offlineConnection


Classes that have changed name;

AdminConnection --> AbstractAdminConnection -- needed the
AdminConnection for the new connection-interface
OpenJMSDestination --> OpenJMSObject -- needed this for OpenJMSUser
as well, thought the name was a bit misleading.

New classes;
CreateLogonDialog
CreateUserDialog
ChangePasswordDialog
OpenJMSUser
OpenJMSObject <--- replace OpenJMSDestination
AbstractAdminConnection <--- replace AdminConnection

I have rewritten how to obtain administred connections:
classes;
ConnectionFactory

interfaces:
Connect <--- contains only connect() and disconnect() is
package-private.
AdminConnection <---
---- Replaces the old
JmsAdminServerIfc
MonitorConnection <---
SystemConnection <--- Not impl. to be used to configure the server:
cache, log, acceptors etc.

Have deprecated JmsAdminServerIfc and AdminConnectionFactory


Modified classes;
see Zip-file.
Have been trying to run a diff against the cvs but the operation gets
canceled evry time so Im afraid you will have to do that .....


K

[Tim Anderson]

+1 to removing the boolean statuses as well.
All of those methods should throw an exception on failure.
-----Original Message-----
From: openjms-developer-***@lists.sourceforge.net
[mailto:openjms-developer-***@lists.sourceforge.net]On Behalf Of Tim
Anderson
Sent: Tuesday, 29 July 2003 4:27 PM
To: Knut at work; openjms-developer
Subject: [openjms-developer] RE: Admin API and GUI


See inline
-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 6:56 PM
To: ***@netspace.net.au
Subject: Re: Admin API and GUI



----- Original Message -----
From: Tim Anderson
To: openjms-developer ; Knut at work
Sent: Tuesday, July 29, 2003 4:26 AM
Subject: RE: Admin API and GUI


Thanks Knut.

I'll commit the changes but I think the new admininistration API needs
to be
thought out more.
We can safely deprecate the existing admin API - you're effectively
working
with a clean slate so you don't need to be tied to the existing method
implementations. If need be, we can also add new JMSException
subclasses
to indicate the reasons for failures. Some of the existing methods
confusingly
throw JMSException but also return a boolean status.

Some of the methods should not throw JMSException at all! User for
instance.
What about a own exception eg. AdminException??
[tima] Yep - thats fine. The advantage of subclassing JMSException is
that
you don't have too many throw clauses which make the API
unwieldy to use.
It just encourages people to catch Exception instead.

Also connect() disconnect() - connect() need to be able to throw
JMSSecurityEx
but all other exeptions have somthing to do with the connection not
JMS.

[tima] I would drop the Connect interface. AdminConnectionFactory
would then
change to

public class AdminConnectionFactory {

public AdminConnection connect(String url, String username, String
password)
throws JMSSecurityException, AdminException;

/**
*
* @deprecated
*/
public JmsAdminServerIfc create(String url) .....
}


Im not very found of boolean statuses for methods doing
add/change/remove
I prefer either void or that they return the Object the are working
with.
All other 'returns' are Exceptions eg. add of a duplicate object is a
Exception not a false.

In particular, I don't see the advantage in separating the
JmsAdminServerIfc
into AdminConnection, MonitorConnection and SystemConnection.

My intention behind this was to separate according to Acl.
To be able to use Admin you must be eg. Administrator
To be able to use MonitorConnection (only read access) it is mabe
enough to have AdminReadOnly.....
Also I find it possible to e.g. write a stand alone appl. to monitor
the system.
[tima] This can be handled within the AdminConnection itself. If a
user attempts to
access an object they are not authorised to use, it would
throw JMSSecurityException.

I would prefer AdminConnection to be the main interface - this would
provide access to destination, security, and server management
objects.

E.g:
AdminConnectionFactory - create an AdminConnection.
AdminConnection - provides access to Destinations, Security, and
Server
objects.
Destinations - topic and queue management.

Server - server management. Probably only a single
method
for the moment, i.e shutdown()
This Is this equal to what I called SystemConnection so we agree on
this.

Security - user, and in future, ACL management

I agree on the separation in Destination/Security when it comes to how
to build the GUI.
But as a Interface this looks like subinterfaces of what I called
AdminConnection.
Reason: Needs the same accesslevel and I likely the user will need
both interfaces in
the same application.
[tima] With the separation you are proposing, an application
potentially needs to
establish three authenticated connections to the server, to
perform administration
functions. The alternative approach above only requires
single sign on,
with the expectation that future ACL management will prevent
unauthorised
operations.

Also, it would be nice if in future the code you submit followed
coding conventions ;)

Of course, but where do I find the conventions??
[tima] Good point. I removed them with the expectation I would have
the maven build
up and running by now - as no-one ever reads coding
convention docs,
its must easier if the build process reports on violations.
Maven runs checkstyle as part of its report generation
process.
You can see the current results here:
http://openjms.sourceforge.net/checkstyle-report.html
As you can see, there's a lot of cleaning up to do. My aim is
to not
introduce new violations, and gradually clean up the existing
ones.

I'm aiming to have the maven build env complete in a week or so - one
of the nice
things it does is include checkstyle reports, so its easy to see what
needs to be
changed.

Regards,

Tim


-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 3:14 AM
To: ***@netspace.net.au
Subject: Admin API and GUI


All src. is based on the latest version from the CVS.

Have made only minimum requirement on the GUI since Im going to
rewrite this during this autumn.
Have not impl. Logon for offlineConnection


Classes that have changed name;

AdminConnection --> AbstractAdminConnection -- needed the
AdminConnection for the new connection-interface
OpenJMSDestination --> OpenJMSObject -- needed this for
OpenJMSUser as well, thought the name was a bit misleading.

New classes;
CreateLogonDialog
CreateUserDialog
ChangePasswordDialog
OpenJMSUser
OpenJMSObject <--- replace OpenJMSDestination
AbstractAdminConnection <--- replace AdminConnection

I have rewritten how to obtain administred connections:
classes;
ConnectionFactory

interfaces:
Connect <--- contains only connect() and disconnect() is
package-private.
AdminConnection <---
---- Replaces the old
JmsAdminServerIfc
MonitorConnection <---
SystemConnection <--- Not impl. to be used to configure the
server: cache, log, acceptors etc.

Have deprecated JmsAdminServerIfc and AdminConnectionFactory


Modified classes;
see Zip-file.
Have been trying to run a diff against the cvs but the operation
gets canceled evry time so Im afraid you will have to do that .....


K

[Knut at work]

See inline
----- Original Message -----
From: Tim Anderson
To: openjms-***@lists.sourceforge.net
Sent: Tuesday, July 29, 2003 6:34 AM
Subject: RE: [openjms-developer] RE: Admin API and GUI


+1 to removing the boolean statuses as well.
All of those methods should throw an exception on failure.
-----Original Message-----
From: openjms-developer-***@lists.sourceforge.net [mailto:openjms-developer-***@lists.sourceforge.net]On Behalf Of Tim Anderson
Sent: Tuesday, 29 July 2003 4:27 PM
To: Knut at work; openjms-developer
Subject: [openjms-developer] RE: Admin API and GUI


See inline
-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 6:56 PM
To: ***@netspace.net.au
Subject: Re: Admin API and GUI



----- Original Message -----
From: Tim Anderson
To: openjms-developer ; Knut at work
Sent: Tuesday, July 29, 2003 4:26 AM
Subject: RE: Admin API and GUI


Thanks Knut.

I'll commit the changes but I think the new admininistration API needs to be
thought out more.
We can safely deprecate the existing admin API - you're effectively working
with a clean slate so you don't need to be tied to the existing method
implementations. If need be, we can also add new JMSException subclasses
to indicate the reasons for failures. Some of the existing methods confusingly
throw JMSException but also return a boolean status.

Some of the methods should not throw JMSException at all! User for instance.
What about a own exception eg. AdminException??
[tima] Yep - thats fine. The advantage of subclassing JMSException is that
you don't have too many throw clauses which make the API unwieldy to use.
It just encourages people to catch Exception instead.

Also connect() disconnect() - connect() need to be able to throw JMSSecurityEx
but all other exeptions have somthing to do with the connection not JMS.

[tima] I would drop the Connect interface. AdminConnectionFactory would then
change to

public class AdminConnectionFactory {

public AdminConnection connect(String url, String username, String password)
throws JMSSecurityException, AdminException;

/**
*
* @deprecated
*/
public JmsAdminServerIfc create(String url) .....
}

[knut]
Personaly I prefer the API to contain the connect(), disconnect() insted of having the the connect()
delivering the API and then only have close() (or disconnect() ) represented inside the API.
Anyway this is not a big deal :-) But if we do it like you described I suggest that we rename connect() to createConnection().



Im not very found of boolean statuses for methods doing add/change/remove
I prefer either void or that they return the Object the are working with.
All other 'returns' are Exceptions eg. add of a duplicate object is a
Exception not a false.

In particular, I don't see the advantage in separating the JmsAdminServerIfc
into AdminConnection, MonitorConnection and SystemConnection.

My intention behind this was to separate according to Acl.
To be able to use Admin you must be eg. Administrator
To be able to use MonitorConnection (only read access) it is mabe enough to have AdminReadOnly.....
Also I find it possible to e.g. write a stand alone appl. to monitor the system.
[tima] This can be handled within the AdminConnection itself. If a user attempts to
access an object they are not authorised to use, it would throw JMSSecurityException.

I would prefer AdminConnection to be the main interface - this would
provide access to destination, security, and server management objects.

E.g:
AdminConnectionFactory - create an AdminConnection.
AdminConnection - provides access to Destinations, Security, and Server
objects.
Destinations - topic and queue management.

Server - server management. Probably only a single method
for the moment, i.e shutdown()
This Is this equal to what I called SystemConnection so we agree on this.

Security - user, and in future, ACL management

I agree on the separation in Destination/Security when it comes to how to build the GUI.
But as a Interface this looks like subinterfaces of what I called AdminConnection.
Reason: Needs the same accesslevel and I likely the user will need both interfaces in
the same application.
[tima] With the separation you are proposing, an application potentially needs to
establish three authenticated connections to the server, to perform administration
functions. The alternative approach above only requires single sign on,
with the expectation that future ACL management will prevent unauthorised
operations.

Also, it would be nice if in future the code you submit followed coding conventions ;)

Of course, but where do I find the conventions??
[tima] Good point. I removed them with the expectation I would have the maven build
up and running by now - as no-one ever reads coding convention docs,
its must easier if the build process reports on violations.

[knut]
+1 for having the build report violations.

Maven runs checkstyle as part of its report generation process.
You can see the current results here: http://openjms.sourceforge.net/checkstyle-report.html
As you can see, there's a lot of cleaning up to do. My aim is to not
introduce new violations, and gradually clean up the existing ones.


[knut]
Could you provide the checkstyle-config file?

I'm aiming to have the maven build env complete in a week or so - one of the nice
things it does is include checkstyle reports, so its easy to see what needs to be
changed.

Regards,

Tim


-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 3:14 AM
To: ***@netspace.net.au
Subject: Admin API and GUI


All src. is based on the latest version from the CVS.

Have made only minimum requirement on the GUI since Im going to rewrite this during this autumn.
Have not impl. Logon for offlineConnection


Classes that have changed name;

AdminConnection --> AbstractAdminConnection -- needed the AdminConnection for the new connection-interface
OpenJMSDestination --> OpenJMSObject -- needed this for OpenJMSUser as well, thought the name was a bit misleading.

New classes;
CreateLogonDialog
CreateUserDialog
ChangePasswordDialog
OpenJMSUser
OpenJMSObject <--- replace OpenJMSDestination
AbstractAdminConnection <--- replace AdminConnection

I have rewritten how to obtain administred connections:
classes;
ConnectionFactory

interfaces:
Connect <--- contains only connect() and disconnect() is package-private.
AdminConnection <---
---- Replaces the old JmsAdminServerIfc
MonitorConnection <---
SystemConnection <--- Not impl. to be used to configure the server: cache, log, acceptors etc.

Have deprecated JmsAdminServerIfc and AdminConnectionFactory


Modified classes;
see Zip-file.
Have been trying to run a diff against the cvs but the operation gets canceled evry time so Im afraid you will have to do that .....


K

[Tim Anderson]

work

<snip>

Post by Knut at work
Personaly I prefer the API to contain the connect(), disconnect() insted

of

Post by Knut at work
having the the connect() delivering the API and then only have close()
(or disconnect() ) represented inside the API.
Anyway this is not a big deal :-) But if we do it like you described I
suggest that we rename connect() to createConnection().

Providing an AdminConnection.connect() method is a code smell.
With this approach you use the AdminConnectionFactory to get
the connection, but then have to invoke connect() before you can
use any of the methods. And if you disconnect(), can you reconnect
again, and if so, why would you want to?

<snip>

Post by Knut at work
Could you provide the checkstyle-config file?

Its available in CVS - or will be in 24 hours. See checkstyle.properties
in the root directory.

[Tim Anderson]

I've committed the changes as is, but I would like to see
modifications as described previously.

One thing to note is that with the current implementation,
it is still possible to invoke admin API methods with
an unauthenticated connection, simply by not invoking
connect().
This needs to be changed so that the admin connection
identifier is submitted with each admin request -
the server can verify this against the list of authenticated
admin connections before performing any operation.

Regards,

Tim
-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 6:56 PM
To: ***@netspace.net.au
Subject: Re: Admin API and GUI



----- Original Message -----
From: Tim Anderson
To: openjms-developer ; Knut at work
Sent: Tuesday, July 29, 2003 4:26 AM
Subject: RE: Admin API and GUI


Thanks Knut.

I'll commit the changes but I think the new admininistration API needs
to be
thought out more.
We can safely deprecate the existing admin API - you're effectively
working
with a clean slate so you don't need to be tied to the existing method
implementations. If need be, we can also add new JMSException subclasses
to indicate the reasons for failures. Some of the existing methods
confusingly
throw JMSException but also return a boolean status.

Some of the methods should not throw JMSException at all! User for
instance.
What about a own exception eg. AdminException??

Also connect() disconnect() - connect() need to be able to throw
JMSSecurityEx
but all other exeptions have somthing to do with the connection not JMS.

Im not very found of boolean statuses for methods doing
add/change/remove
I prefer either void or that they return the Object the are working
with.
All other 'returns' are Exceptions eg. add of a duplicate object is a
Exception not a false.

In particular, I don't see the advantage in separating the
JmsAdminServerIfc
into AdminConnection, MonitorConnection and SystemConnection.

My intention behind this was to separate according to Acl.
To be able to use Admin you must be eg. Administrator
To be able to use MonitorConnection (only read access) it is mabe enough
to have AdminReadOnly.....
Also I find it possible to e.g. write a stand alone appl. to monitor the
system.

I would prefer AdminConnection to be the main interface - this would
provide access to destination, security, and server management objects.

E.g:
AdminConnectionFactory - create an AdminConnection.
AdminConnection - provides access to Destinations, Security, and
Server
objects.
Destinations - topic and queue management.

Server - server management. Probably only a single
method
for the moment, i.e shutdown()
This Is this equal to what I called SystemConnection so we agree on
this.

Security - user, and in future, ACL management

I agree on the separation in Destination/Security when it comes to how
to build the GUI.
But as a Interface this looks like subinterfaces of what I called
AdminConnection.
Reason: Needs the same accesslevel and I likely the user will need both
interfaces in
the same application.

Also, it would be nice if in future the code you submit followed coding
conventions ;)

Of course, but where do I find the conventions??
I'm aiming to have the maven build env complete in a week or so - one of
the nice
things it does is include checkstyle reports, so its easy to see what
needs to be
changed.

Regards,

Tim


-----Original Message-----
From: Knut at work [mailto:***@royalhighgate.com]
Sent: Tuesday, 29 July 2003 3:14 AM
To: ***@netspace.net.au
Subject: Admin API and GUI


All src. is based on the latest version from the CVS.

Have made only minimum requirement on the GUI since Im going to
rewrite this during this autumn.
Have not impl. Logon for offlineConnection


Classes that have changed name;

AdminConnection --> AbstractAdminConnection -- needed the
AdminConnection for the new connection-interface
OpenJMSDestination --> OpenJMSObject -- needed this for OpenJMSUser
as well, thought the name was a bit misleading.

New classes;
CreateLogonDialog
CreateUserDialog
ChangePasswordDialog
OpenJMSUser
OpenJMSObject <--- replace OpenJMSDestination
AbstractAdminConnection <--- replace AdminConnection

I have rewritten how to obtain administred connections:
classes;
ConnectionFactory

interfaces:
Connect <--- contains only connect() and disconnect() is
package-private.
AdminConnection <---
---- Replaces the old
JmsAdminServerIfc
MonitorConnection <---
SystemConnection <--- Not impl. to be used to configure the server:
cache, log, acceptors etc.

Have deprecated JmsAdminServerIfc and AdminConnectionFactory


Modified classes;
see Zip-file.
Have been trying to run a diff against the cvs but the operation gets
canceled evry time so Im afraid you will have to do that .....


K

[Knut at work]

see inline

----- Original Message -----
From: Tim Anderson
To: openjms-developer
Sent: Tuesday, July 29, 2003 3:58 PM
Subject: [openjms-developer] RE: Admin API and GUI


I've committed the changes as is, but I would like to see
modifications as described previously.

One thing to note is that with the current implementation,
it is still possible to invoke admin API methods with
an unauthenticated connection, simply by not invoking
connect().
[K]
Thats correct, I didnt impl. this since I didnt know how you wanted it done.

This needs to be changed so that the admin connection
identifier is submitted with each admin request -
[K]
Do you want to use the ClientId, ConnectionId (returned form the server on
connect()) or both?
As I see it the ClientId alone is not unique enough since it is possible to
generate duplicates.

the server can verify this against the list of authenticated
admin connections before performing any operation.
[K]
This is as I see it a part of the authorization and should be treated in the
Acl.
We could of course make a quick solution for now by just check the id for
every operation.

Do you want to have a AuthorizationMgr to handle this or do you want to have
a common Mgr e.g. SecurityMgr to handle both Authentication and
Authorization??


Regards,

Tim

[Tim Anderson]

Create an AdminConnectionMgr class to handle AdminConnection
instances. This should use AuthenticationMgr to authenticate
connection attempts, and assign a unique identifier to
authenticated connections.

When AdminConnection methods are invoked, they should submit
the identifier so it can be verified against the list of active
admin connections maintained by the AdminConnectionMgr.

ACL support can be added later, post 0.7.6.

Regards,

Tim

Post by Tim Anderson
-----Original Message-----
at work
Sent: Friday, 1 August 2003 9:59 PM
Subject: Re: [openjms-developer] RE: Admin API and GUI
see inline
----- Original Message -----
From: Tim Anderson
To: openjms-developer
Sent: Tuesday, July 29, 2003 3:58 PM
Subject: [openjms-developer] RE: Admin API and GUI
I've committed the changes as is, but I would like to see
modifications as described previously.
One thing to note is that with the current implementation,
it is still possible to invoke admin API methods with
an unauthenticated connection, simply by not invoking
connect().
[K]
Thats correct, I didnt impl. this since I didnt know how you
wanted it done.
This needs to be changed so that the admin connection
identifier is submitted with each admin request -
[K]
Do you want to use the ClientId, ConnectionId (returned form the server on
connect()) or both?
As I see it the ClientId alone is not unique enough since it is
possible to
generate duplicates.
the server can verify this against the list of authenticated
admin connections before performing any operation.
[K]
This is as I see it a part of the authorization and should be
treated in the
Acl.
We could of course make a quick solution for now by just check the id for
every operation.
Do you want to have a AuthorizationMgr to handle this or do you
want to have
a common Mgr e.g. SecurityMgr to handle both Authentication and
Authorization??
Regards,
Tim
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072
303_01/01
_______________________________________________
openjms-developer mailing list
https://lists.sourceforge.net/lists/listinfo/openjms-developer