- Sanitation: Make sure we don't end up with injection issues by addressing $_REQUEST and/or $_POST directly
- Extendability: Make sure the code has it's hooks and extendability in all major parts of the security implementation, without compromising the security itself.
- Security: Making it easier to implement your own security methods, if you wish to do so. Right now, for example, the salt and encryption methods are stored in the member database table. Should this be moved to a new table, or maybe be peppered with a hash (I don't think the last part is needed, but if highly requested, I can look into it).
- Extraction: Right now, Security and Framework are very much tied together. I'd like to extract it to support custom CMS modules. This is a far-fetched goal though.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
- Security: Making it easier to implement your own security methods, if you wish to do so. Right now, for example, the salt and encryption methods are stored in the member database table. Should this be moved to a new table, or maybe be peppered with a hash (I don't think the last part is needed, but if highly requested, I can look into it).
First of a few questions regarding your to-do list:
- Sanitation: Make sure we don't end up with injection issues by addressing $_REQUEST and/or $_POST directly
In what ways specifically are external input not already sanitized properly for authentication reasons?
- Extendability: Make sure the code has it's hooks and extendability in all major parts of the security implementation, without compromising the security itself.
Are there specific examples of what you'd like to have be more extensible which are not currently able to be done without core modification?
- Security: Making it easier to implement your own security methods, if you wish to do so. Right now, for example, the salt and encryption methods are stored in the member database table. Should this be moved to a new table, or maybe be peppered with a hash (I don't think the last part is needed, but if highly requested, I can look into it).
A quick look at the code (from what I can tell) reveals that you can either A.) Override MemberAuthenticator with your own custom class and use the Injector to ensure the system uses your overridden version of that class to more completely/fundamentally override how authentication currently works (including I believe decoupling the tight binding to the email field I suppose), or B.) Do the same thing for the Member class as well and simply change how (or where) those fields are stored, if you wanted to retain the "Member" table but store it somewhere else for whatever reason.
- Extraction: Right now, Security and Framework are very much tied together. I'd like to extract it to support custom CMS modules. This is a far-fetched goal though.
You mean abstracting "Security" into it's own module (similar to how SiteConfig was for v3.2 or v3.3 I believe) correct?
Anyway, for my "wannahaves", I'd love to see:
- Very Important: Require a user to enter their own password first prior to resetting their password. At the moment, the user only needs to confirm the new password they just typed (for accuracy). Not to confirm that they're not just some person who walked up to a person's already-open session.
- An easier and more intuitive way to allow users to change their own password. Amazingly there's no obvious option to do this in the CMS "out of the box"!
- Email notifications to notify users that their password has been changed or reset.
- An easy way to incorporate two factor authentication. How that'd be done I have no clue :) e.g.
- Maybe expose an API to salt the password with an RSA ID prefix (rolling code, shared secret) as the user types it in or
- Maybe allowing the injection of a second authentication form which requires that second input (e.g. value from a text message).
- Specific use case (but common one) as an example to help set a goal: Perform a review of the core code base to ensure that the API is opened up enough add standard support for SAML SSO (Single Sign On). In case that's not already possible.
I think that first item is more important than everything else (albeit it doesn't relate to initial login). But it's an important feature that I'm amazed doesn't already exist; at least not in 3.3.
--
You received this message because you are subscribed to a topic in the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/silverstripe-dev/308k1-RP-4M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
If you want my two cents it would be fantastic to add redirects based on group or permission roles into the admin of security along with offering the ability to choose the templates in use for each group/member.
I have just spent some time extending both the Security class and the AdminLogin stuff to achieve this but it was complicated to say the least. I'm not with the code at the moment but I can send it to you later of you want to see my working example?
All the best,
Mark
Regarding the hooks. Its not a Security only issue, but an SS issue, but :
All those onAfterSomething(); method call hooks. I cant remember them or find them if they are added somewhere. And those only work for Extensions
An event()->fire('user_logged_in'); that can be used in an EventListener would be nice. (yes we can list the alle events quite easy then)
But after all it works pretty decent for most thinks what I need for more then over 7 years by now ;)