On 6/7/13 11:49 PM, Sean Mullan wrote:
try {
send(initSecContext(inToken));
} catch (GSSException e) {
if (e.getResidue() != null) {
send(e.getResidue());
}
throw e;
}
That doesn't seem too complicated to me, all things considered. I think
this would be a reasonable solution. I would simply name the method
getToken instead of getResidue.
Or getOutputToken()? If the incoming token is a KRB_ERROR,
initSecContext(token) will also throw a GSSException. Although I don't
plan to provide a method to retrieve the incoming token, getToken()
might be confusing.
As for the overloaded initSecContext(InputStream, OutputStream) style,
it looks easier to update this method to do the correct thing without
any new API. However, the change will be very confusing because there is
no more number of written bytes to return. More importantly, if it's
just a silent behavior change, we'll have to care about compatibility
(Maybe someone already added his/her own KRB-ERROR sending codes?),
which makes the situation much tougher.
Can you describe how the application code would use this method like you
did above for the other initSecContext method?
The recommended way was
while (!context.isEstablished()) {
context.initSecContext(is, os);
os.flush();
}
When I say "easier", I mean it looks like there is no need to make any
application change and this method can just write KRB_ERROR into os and
*then* throw the exception.
But this is a behavior change and can be quite dangerous. I'd rather
also write
while (!context.isEstablished()) {
try {
context.initSecContext(is, os);
} catch (GSSException e) {
if (e.getOutputToken() != null) {
os.write(e.getOutputToken());
os.flush(); // in finally? not sure.
throw e;
}
}
os.flush();
}
and add a clarification to the method saying no bytes will be written to
os if there is a GSSException.
Thanks
Max
--Sean
Thanks
Max
[1] http://tools.ietf.org/html/rfc2743#page-46
