I'm migrating some custom code for subscription management, and it brings up some interesting issues with user logon trust.
Basically, because we are primarily dealing with user profile information for email subscriptions, we have different "trust" levels of believing someone is who they say they are. For example, if someone is unsubscribing from a list and gives us their email address and a selection of lists they no longer wish to receive - than in that case we don't require a logon of any sort, we just immediately accept the unsubscribe information, update the records, and send a notice letting them know. [Legally you cannot require anything beyond a single page unsubscribe from a user. No captcha codes. No second page confirmations. Etc.] If, on the other hand, someone is SUBSCRIBING to a list and they don't have an account, we need to confirm their subscription information with a double opt in process. Add to that if someone clicks on any unsubscribe link in an email, embedded in that link are codes unique to them so we can pull up their entire subscription list and let them opt out. For convenience purposes[see 1] we might as well accept that link as authorizing them to see the list subscriptions associated with the account. Additionally, if someone clicks on any link in an email, asking them to authenticate again for MOST functions is undesirable, assuming it was a recent email. If however the mail is 6 months old, then we don't want to trust that link as much. Finally, since the same system can give one access to demographic data one has entered, or in the case of clients, campaign data for their advertising, at that point we don't want to give them access to those areas without an extra confirmation[and note: not everyone has passwords, so some of these confirmations will be yet more email links!] Basically, what it comes down to is when someone tells us who they are, there are different levels of "trust": 1) Unsubscribe, without showing them subscription info: trust anyone 2) Unsubscribe/Change subscriptions: any valid logon link from the past month is sufficient 3) Demographic/personal details: Valid logon links from the past week 4) Company data of some sort: Password or specific logon link from today only 5) Internal company data: Passwords only Add to that that there are certain functions, such as FTAF where we want to accept most people from category 2 for the first 5 people forwarded to...after that, we want either option 3 OR prompt for a captcha code to avoid being used as a FTAF spam source. What this comes down to is that there are different levels of "trust" for a logon[we could also add in a deterioration "remember me" cookie, so after a few days someone at level 5 go to level 4 then level 3 then level 2 and will be prompted to re-enter their password. Most systems have a simple binary off/on...perhaps a link to something like syslog and fail2ban in order to lock out repeated excessive logon attempts, but no real definition of "trust". I was wondering what others thoughts on this issue is...beyond that I am overcomplicating things unneccessarily. :-)
_______________________________________________ New York PHP SIG: Joomla! Mailing List http://lists.nyphp.org/mailman/listinfo/joomla NYPHPCon 2006 Presentations Online http://www.nyphpcon.com Show Your Participation in New York PHP http://www.nyphp.org/show_participation.php
