Abstraction

Revision as of 04:34, 27 July 2009 by Wickr (Talk | contribs) (Reverted edits by 119.167.225.136 (Talk); changed back to last version by Wickr)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Revision as of 04:34, 27 July 2009 by Wickr (Talk | contribs) (Reverted edits by 119.167.225.136 (Talk); changed back to last version by Wickr)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)


General rule: Abstract things out as much as makes sense

Specific rule: Abstract the living crap out of your authentication scheme.

Look, pretty much everyone with anything worth protecting already has an auth/authZ infrastructure in place. Sometimes an extensive, perhaps multi-institutional infrastructure. One that isn’t going to be bypassed without, say, getting fired.

So if you’re going to require people to log in, make sure you make that process as abstract as you possibly can, both in algorithm and in code. Have a singleton class that’s easily subclassed to represent your user, and call it exclusively. Make sure that your URIs are easily separated into those that require auth and those that don’t, for simple use of mod_rewrite or whatnot to redirect to authentication. Make sure it’s easy to hook into (or work around) AJAX links that might require authentication that has expired.

And for the love of god, don’t stuff username/password information into a cookie if you’re doing web work. Use a session and session key. Any auth scheme that I can spoof is no auth scheme at all, because I’m an idiot and not even trying hard.