Hi Enrique,
Enrique Rodriguez wrote:
On 10/26/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Hi,
I'm currently reviewing the Ticket structure, and I'm wondering why we
do store the encrypted data _and_ the encrypted ticket part,
considering that the first structure is a sealed version of the second
one ? I understand that it is an optimization as we will manipulate a
lot the data from the second structure, but why can't we simply extend
the Ticket class to add a new field (this encTicketpart) in the
inherited part?
I think of the Ticket as existing in 2 states: sealed and unsealed.
Therefore, it makes sense to have one Ticket but have it handle the 2
states better, such as returning an IllegalStateException instead of
the current NPE if an attempt is made to access the EncTicketPart
without decrypting it first.
It makes sense. As we have to access this unsealed data everywhere in
the code (I have discovered this while browsing the code), keeping both
sealed and unsealed values within the Ticket structure is better.
Now, I'm wondering if it's a good thing to also provide the accessors to
this unsealed value in the Ticket class. I would favor this kind of access :
ticket.getDecryptedTicket().getClientAddresses()
instead of :
ticket.getClientAddresses()
At first sight, it seems that the second form is lighter, but it has the
big inconvenient to duplicate the accessors : you already have a
getClientAddesses() method in the EncTicketpart class.
Something like :
Ticket
{
int versionNumber;
KerberosPrincipal serverPrincipal;
EncryptedData encPart;
}
and
TicketWithTicketPart extends Ticket
{
EncTicketpart encTicketPart;
}
I don't know... wdyt ?
This might work. I can see how the API would return the 2nd form
after a decrypt. Though, it might be better named as "Ticket" and
"DecryptedTicket."
Very true. Excuse my deficiencies in english :)
With both the names your are suggesting here and
the other renames you have made I believe you are coming at an
understanding of Kerberos from the ASN.1 structures, when the
higher-level (and less literal) naming will be better with the
protocol workflow in mind.
I like to have basic structure being as close as possible to the ASN.1
names, because it helps people who read the RFCs to get a quick
understanding of the code. But I also have some concerns when it comes
to implement, say, 'sname'. Ticket.getSName() is really not the best
method call I ever saw, compared to Ticket.getServerName().
I don't know. The idea is to discuss all those kind of questions in
order to share the ideas and have the best solution, as a community.
If you tell me that getSName() is far from being perfect, I will just
switch back to the previous name :) (anyway, I don't like this name
either... )
Thanks !
