I’m looking to migrate a number of projects to SilverStripe, some have authenticated users. One is for an online shop, the other an event website. Requirements are quite different between them.
I’m struggling to find any add-ons or plugins that provide this. Is there any?
Old posts I read seem to be pointing saying I should extend SS’s core authentication used for getting into the CMS itself.
Is that the way to do it? These front end users share very little with my store owner/SS users. I really don’t want them in the same table.
The built-in Member class is intended to handle authentication, but by default Members don’t have any special privileges, so there’s no harm in using the same authentication system for logging in to the CMS and letting users log in to your store. You can create Groups and Roles to manage what different types of users can do.
I’ve seen a handful of e-commerce and event modules around in the past but I haven’t looked lately so I’m not sure if any are being actively developed.
Thanks for the reply Jono.
I’m reading here: Members – SilverStripe Documentation
I think I see how I can use the classes etc to get this done. I can’t seem to find a shred of documentation on how to get this done… weird.
Still a bit confused around the database side of things. None of these users should have CMS access. Am I meant to get a new member instance and config it’s table name to point to my own table?
I know you mentioned roles etc but there’s a bunch of related data off these users (transactions/orders/wish lists) etc and doesn’t make a lot of sense for me to lump these into the CMS user table. 1 or 2 CMS users compared to 1000’s of store front users.
I’m in my first few days of SS so apologies if these are Billy basic questions.
All good Lance. When you create a new user (Member) in SilverStripe, they don’t have CMS access. Unless you grant a user any special permissions, all they can do is log in to the website. (And reset their password, and log out of multiple devices at once). Basically, they can authenticate with your website, with zero effort on your part, so thats a win 
You can grant a Member access to parts of the CMS or full Admin rights if you wish, but none of that happens on it’s own. Member is just a component you can build on.
In terms of not cluttering up the Member table, if you need to add some additional fields but don’t want all Members to have them, you could subclass Member to create a StoreUser class or something, that has additional database fields. Those would be stored on a separate table.
But, from the examples you gave (Transactions, Orders, Wish lists) - I would say that none of this information should be stored on the Member table. You would create a separate table for Transaction, Order and WishList, which would each have a MemberID field, which takes care of linking those records with an applicable Member. Only your Members that use the store functionality would end up with records in these tables.
In you model it would look like Transaction has_one Member, and on the opposite end, Member has_many Transactions. Here is some documentation on that: https://docs.silverstripe.org/en/4/developer_guides/model/relations/
If you’re new to SilverStripe development I would highly recommend going through the video lessons. @unclecheese put a lot of effort in to them and they will make things click really quickly for you!
I see! I didn’t realise that by default created members didn’t have CMS access. That makes sense of the CMSLoginHandler and LoginHandler in MemberAuthenticator.
I have been through all the lessons and carried on with it to make more modules and template the forms etc that wasn’t covered.
You’re right that the extra fields I’d need in the members table aren’t a big deviation and all the related data is off in other tables. However given the purpose of the data sub classing seems the best way to go.
All the users current login creds are going to be busted aren’t they… They’re salted with a db field and a file based hash currently. I’ve not long updated the site and had to get them all to redo their password… ah well. (sorry I’m thinking out loud).
Thanks for the help
If you’re subclassing Member I guess you could override some of the password functionality but I would go with a reset myself 