Story #2645
Session handling in java service api
100%
Description
The java service api currently includes a Session parameter for most methods, used to indicate the identity of the client (determines the certificate used for setting up SSL). The behavior is that if null, the certificate in the default location used by CILogon is used.
Since most of the time the default is used, it was proposed that the Session parameter be removed from all d1 service api calls. The portal and integration testing both make use of non-default certificates/sessions, so the ability to set the Session is still a requirement. The secondary proposal is to move the Session parameter into the constructor of the D1Node.
Whatever the solution requires minimal to zero component refactoring, outside of common_java and libclient_java.
Subtasks
History
#1 Updated by Rob Nahf over 12 years ago
- Category set to d1_common_java
- Assignee set to Rob Nahf
#2 Updated by Skye Roseboom over 12 years ago
exposing a public getter/setter pair on the D1Node would also provide a means of changing the session / subject when needed.
#3 Updated by Robert Waltz over 12 years ago
In the API implementations, the subject is pulled out of the session and used as local variable in business logic of a few methods. The subject will need to be passed in to the functions (having been pulled from the 'session') before calling them.
All authorization code must be pulled out of methods and occur as an aspect of (or orthogonally to) the service container.
#4 Updated by Rob Nahf over 12 years ago
wrt/ set/getSession: It's not the setting/getting of the Session member variable that's an issue.
It's that both the session-less methods and the old methods use null to indicate different desired behaviors regarding what session to use.
for example:
public InputStream get(Identifier pid) {
return get((Session) null, pid);
}
In this case, you'd want a null Session passed to get(Session, Identifier) to use the getSession() value.
Whereas existing code expects that a null sent to get(Session, Identifier) uses that null value.
If we assume that existing code would not be using setSession(), or D1Node(baseurl, Session) - and thereby also returning null from getSession() - we leave open the possibility for unexpected behavior for the unknowing.
The issue is probably avoided by having the session-less methods pass a special Session object that indicates that the getSession() value be used, and a null Session uses null.
#5 Updated by Rob Nahf over 12 years ago
- Status changed from New to Closed
updated all components, and updates architecture conformity tests in d1_integration to account for the session-less methods compared against the session-containing documentation.
