I have a few questions about how Transactions are used in Ipsilon.
Each of the AuthenticateRequest classes (openid, persona, saml2)
create a Transaction object in their _preop handler. But
KrbAuth.root(), KrbError.root(), LoginFormBase.root(), Login.root(),
Cancle.GET() all call get_valid_transaction(). I'm trying to
understand the semantic differences between the two approaches.
As far as I can tell the only signficant difference is that
get_valid_transaction() also looks for the id in the referer,
otherwise it's almost the same logic.
What's the fundamental reason for the two approaches?
get_valid_transaction() can raise a ValueError for an expired
transaction but I don't see any logic that enforces that. Also if the
transaction does not exist it creates a new one, as far as I can tell
the only thing that will trigger the execption is if the UUID provider
cookie is absent.
Let's talk about the cookies in the transaction for a moment, a
Transaction has 2 cookies, the ipsilon_transaction_id cookie is
obvious. But there is also a cookie whose name is a UUID and value is
the provider. What is this being used for? The only reference I see to
it are in the AuthenticateRequest._preop() methods. It checks to see
if the UUID cookie value (provider) matches the handler processing the
request.
Why is the transaction provider check necessary? All it does is log a
debug message.
Why isn't the logic to compare the UUID cookie value to the provider
inside the Transaction constructor or get_valid_transaction?
It seems like we have a lot of cut-n-paste duplicated code for
transactions and/or code that differs only insignificantly that could be
parameterized instead. Any reason why this code isn't in one common
shared utility?
A few more questions but related to the unique_data storage system
that transactions utilize.
Do I understand correctly that the unique_data system stores data
under a key whose value is a dict and that each time save_unique_data
is called the passed in dict is used to update the stored dict, thus
the stored dict accumulates new key/value pairs on each save (and or
replaces the value of an existing key). Did I get that right?
If that correct then isn't there a possible problem with name
collisions by components that store into the transaction but are
unware of the names in use? For example the transaction stores under
the name "cookie", that's a pretty generic name, what prevents someone
else from using the same name and corrupting the transaction data?
If the tranaction object where we expect to store *all* data unique to
an operation? It might seem like there is an obvious answer because of
the assumption occur across multiple requests. But there are some
operations that are handled in only a single request, there is no
logical need for a transation object in this case, other than it's
just a handly place to hang data that all components in the code can
utilize. Is that the thinking?
--
John