You can use security to prevent access to certain parts of your solution. That and the interface provided will prevent students from accessing the other parts of the solution.
Hi Jaymo, I'm aware of that ;-)
I just wanted to have a general direction, since both paths will have pro's and con's - and it'll take me a long time to walk both paths & decide which one is more convenient in the long run.
Right now I'm more inclined into splitting them up. Reasons:
- target audience is fundamentally different: anonymous customers vs employees
- anonymous access requires some settings, that make logging in more error-prone (holding in ALT keys etc)
- theming is different
- security is easier to manage in a split scenario
2 of 2 people found this helpful
If you truly need anonymous login, you may consider a sync method and push/pull data as needed to separate databases & tables. Lock down for view only on the new set of data and web publish it. You can limit what gets pushed for anonymous without ever having your "real data" web published. It can even be different servers (or even different dbs - MySQL for example, should you have that need).
1 of 1 people found this helpful
To future readers: this is what I actually did:
First, I really split up the db, making the main database for backoffice purposes only, and a smaller, public one, with web-accessible forms for anonymous users.
- focus & easy of form, layout, theme management
- backoffice users are logged in right away, public users are logged in as guests right away
- getting access rights okay
- getting data back & forth: often, I'd notice an extra field that needs to go on the form, and then I had to make modifications in the 2 db's. To be expected, but quite a hassle.
- after submitting a form, some scripts need to run. I didn't want them to run under "Internet access" user rights, since they might create/modify data all over the place.
- sharing value lists is doable, but
Eventually, as i progressed, I made the decision to merge it all back into one database.
- access rights: are easily managed from within the one db
- theming: no prob, I now have a back-end theme for backoffice screens and a website-theme for the webform pages
- data handling & scripting: much easier. Changes to db structure & form go hand in hand. Data handling scripts are easier to build & fire.
- a bit more learning curve, but very worthwhile in the end
If your setup is not too different from mine, I recommend keeping both private and public parts in one db.