I am designing a system where Front End Visitors can add/edit/remove content.
The main issue I've run into is members vs users. The API always has a user create ndoes in the back office, not members. If I use the API to create content I can give it the ID of the user creating the content, however the Member is not a back office user, so I just use 0 "admin" everywhere.
Then all the content says "Created by Admin" and "Updated by Admin". So I added Member Created/Update properties to all of my content...
But I was thinking I don't really need to use membership at all.. I could log in to the front end as a User, SSO straight into the back office, and then block all the users from being able to access the back office with the "Disable Umbraco Access" toggle.
Hopefully I can still create content as them with that set with the API.
Technically their is no reason you can't use users as members, but from a security point of view i would try to avoid it.
Users of Umbraco have a lot more access to the backend than members, once logged in as a user, you can obviously create and update content but you can also potentially do other things such as update templates and stylesheets and back office settings.
Even with the back end 'disabled' - user accounts will still be able to call backoffice web services that make umbraco tick, so it opens up quite a bit of the site for potential hackery.
I would (and have in the past) stick to Members for user generated stuff, using your member create/updated properties - This way members can only get to the content you want them to get to, and they can't go around messing with other bits of the system - even by accident.
For your core editors their might be odd little are you logged in the front or back end things, (but these are increasingly rare) - but your site will be way more secure.
Is there any reason not to use Users as Members?
I am designing a system where Front End Visitors can add/edit/remove content.
The main issue I've run into is members vs users. The API always has a user create ndoes in the back office, not members. If I use the API to create content I can give it the ID of the user creating the content, however the Member is not a back office user, so I just use 0 "admin" everywhere.
Then all the content says "Created by Admin" and "Updated by Admin". So I added Member Created/Update properties to all of my content...
But I was thinking I don't really need to use membership at all.. I could log in to the front end as a User, SSO straight into the back office, and then block all the users from being able to access the back office with the "Disable Umbraco Access" toggle.
Hopefully I can still create content as them with that set with the API.
Hi
Technically their is no reason you can't use users as members, but from a security point of view i would try to avoid it.
Users of Umbraco have a lot more access to the backend than members, once logged in as a user, you can obviously create and update content but you can also potentially do other things such as update templates and stylesheets and back office settings.
Even with the back end 'disabled' - user accounts will still be able to call backoffice web services that make umbraco tick, so it opens up quite a bit of the site for potential hackery.
I would (and have in the past) stick to Members for user generated stuff, using your member create/updated properties - This way members can only get to the content you want them to get to, and they can't go around messing with other bits of the system - even by accident.
For your core editors their might be odd little are you logged in the front or back end things, (but these are increasingly rare) - but your site will be way more secure.
is working on a reply...