4 Replies Latest reply on Jun 8, 2017 1:20 AM by wimmmmm

    How to split up my db to allow partial web anonymous access?

    wimmmmm

      Hi,

       

      I'm making a student organization db for a music school, with

      • students,
      • teachers,
      • subscriptions to classes,
      • payment info

      and such.

       

      This is to be the backoffice for this music school, they will use Filemaker, Filemaker Go and a bit web access to manage all this data.

      All teachers will have their own account & will log in.

       

      Now, ideally we'd like for all students (new & existing) to fill out some forms, to apply for new classes.

      They don't really need a student account, they will subscribe just twice a year.

      We already have an operational site. I expect to add some URLs to these pages, to point to the correct forms with no visible transitional glitches.

       

      My main question is: should I split up my db into a backoffice part & a public website part, for ease of access management? Or should I keep it all in one large db? I'm inclined to split it up, but right now I stumble into rights problems:

      • The forms on the website will use backoffice Value Lists (names of teachers, instruments etc), and will post data into a backoffice table for further treatment. (I can't seem to grant access to the anonymous users to see this Value list)

       

      What would you advise?

        • 1. Re: How to split up my db to allow partial web anonymous access?
          Jaymo

          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.

          • 2. Re: How to split up my db to allow partial web anonymous access?
            wimmmmm

            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
            • 3. Re: How to split up my db to allow partial web anonymous access?
              beverly

              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).

               

              beverly

              2 of 2 people found this helpful
              • 4. Re: How to split up my db to allow partial web anonymous access?
                wimmmmm

                To future readers: this is what I actually did:

                 

                The split

                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.

                Pro:

                • focus & easy of form, layout, theme management
                • backoffice users are logged in right away, public users are logged in as guests right away

                Cons:

                • 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

                 

                The merge

                Eventually, as i progressed, I made the decision to merge it all back into one database.

                Pro:

                • 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.

                Con:

                • a bit more learning curve, but very worthwhile in the end

                 

                Conclusion

                If your setup is not too different from mine, I recommend keeping both private and public parts in one db.

                1 of 1 people found this helpful