Here's some replies I promised.
Can we provide a single config file that can be read by the app? No. But not for the reasons you put forth. That way a user can specify some important information in a single place without having to do anything with the app. Things like telling the app if there is a user form to include (and if not, we can add in a canned one), if they will be using a database or files for user data, etc. That way we can effectively develop the app without the need for a user to do anything inside of it. They shouldn't need to do any edits. But you don't need a configuration file. What do you all think about this idea?
My responses in bold. Here's my assertion: configuration files, in there essence, are global pieces of information. Globals are usually frowned upon, because it's difficult to track what's going on with them, but are quite useful when a particular parameter needs to be passed several levels deep and you don't want to bubble it through parameters.
There is no need, however, for the Authentication component to have to do this. Passing everything by parameter, at this point, is still quite feasible.
However, if people insist, we can add another function wrapper that can pass a configuration array. More features.
On the use-case creep - As we add even more and more ways to use the application, it will be difficult to instruct users how to use it at all (Oh, you can use this class in 100 ways). Perhaps we could classify them from most intrusive to least intrusive or something, or perhaps organize them "wizard"-style?
Yes, I think that the Auth code should have no dependencies on any presentation code -- PEAR::Auth does it that way with callbacks.
So you force it the other way: the auth code is not dependent on presentation, the presentation is dependant on Auth code! That is, the presentation has to know about how to get info from the auth code, even if it's through some mediating wrapper. We could bundle a Smarty extension with our app to facilitate login form generation.
As I have said, I think the application should acquire the credentials (whether username/password or remember me cookie), provide the known datasource (to validate againse), and a persistence mechanism (for session data).
Agreed, but the auth module also needs to be able to autodetect this stuff.
We can certainly supply some canned presentation code to make building simple login pages easier though.
Some of the most spectacular extra features (notably challenge/response and RSA encryption) will require a substantial bit of client-side work. Then the canned presentation code becomes a must.
Also, I'm trying to think of a good excuse to use SPL Observer
Try not to get too attached to SPL. Not everyone knows what they are. (I do know what they are but have never used them)
Santosj's code at
this post - I finally think I understand it. And that wasn't an easy process. Reflection makes stuff so much harder to use.
Santosj, if we really needed the form to be that configurable, I'm sure the developer would have their own pet form generation system. Plus, I don't see why we couldn't just...
Code: Select all
$authform->paintStart('confirm.php');
$authform->paintUsername();
$authform->paintPassword();
$authform->paintEnd();
And I've done this before and it's a pain. Sorry, but no.
arborint's code from
this post
My previous objection could be circumvented with santosj's suggestion that the raw post data just be serialized and then reinstantiated when the user travels back to the appropriate page. This is, however, out of our scope, because there are security/filesystem implications for things like uploads and passwords (which ideally aren't persisted in plaintext form).
The code is awesome. Do you have down what all of the classes are at this point?
No, but that use code shows us what the API looks like.
User/password as exceptions
I agree that they shouldn't be exceptions, but for different reasons. Any controller worth its salt should be able to intercept a not authorized/bad login credentials and redirect application flow to the appropriate page. Plus, the thin-ness of application should make it possible to bubble it all the way up without too much problem (the greatest feature of exceptions is the ability to bypass this bubbling).
I need a little time to think about the code you posted.
I'd like to hear a reply some time or another, because I'm going to be augmenting that code pretty soon.
Htaccess does everything in and of itself
Correct. We're not dealing with htaccess.
HTTP basic authentication.
That's another way to get credentials, and it's probably the way to manage authentication for a user who doesn't accept cookies.
Yes, all replies done!