This is the new auth.inc.
You need to substitute this and the following
Changes in the API are being reduced at minimum.
The explanation follows
I was reflecting on the rationale behind this
whenever a login or register form is showed out, The
auth object is
initialized with the
This is done in method start of auth class.
Then, only if this value is set to 'form', the
(reg/log) is tested, and a registration or a login is
attempted with the
This too is done within the start method of class auth.
All this is not taken into account if you provide your
I don't know why this intermediate state has been
coded, I suppose there
can be some safety gains, and maybe you can point me to
One I can think of is that you block
'post-and-register' submissions (in
fact is getsession-post-and-register), because that
value has to be set
What other can be the end of having that intermediate
Is the end to forces you to have obtained already a
sobmitting a login o register form.
As an aklternativa, to get the same, I think that you
could pass a
'session' input field, and the that has to contain a
But this causes a whole lot of problems, among which:
-you cannot simply show a login or register form
anywhere, 'cause it's
input won't be taken in consideration, not being
-once a for is showed yu are stuck and need the
cancel_login button to
The auth->mode log/reg issue is very incumbrent too, at
least being it
handled from inside auth. You are stuck with the same
policy all over.
I'd prefer it to be decided by me, when I need to put
out a form. The
form should contain an input field, that can be named
value 'register' or 'authenticate' (the default).
Because otherwise, when the behavior is not the
intended, we have to dig
into method $auth->start, see what 'mode' value has
arrived down to
there (and hey, there are two $mode: one is auth->mode
the other is the
get param in the url ?mode=log that should serve to
force the show of a
form different from the one stated in $auth->mode...
at the moment).