Jump to content

Dual File Login

This topic is 5481 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Ummm, right, i brought up a point about where i should store my accounts a fair while ago in my backend (serverside) / frontend (clientside) split. Backend was logically decided to be the place to store the accounts.

I have three issues. Firstly, the scripts which i've attempted to place into my backend and execute in my front end work as follows: when the back-end file is open, it will generate / suspend the account for the currently viewed record in the BACKEND. So the front end record that is being viewed is not the record which the script manipulates. Secondly it doesn't work at all when the backend file is not open. I am using the "Perform Script" script step and am simply executing the script in the referenced backend file. Could somebody please clear up my logic here?

Second issue is the following. Because it was decided that the accounts would be located in the backend, i created 2 global fields to be set on start up and called throughout all my front-end scripts in the place of get(AccountName) & get(privelegesetname): gAccountName, gAccountPrivSet.

I need to set these...

Third and final issue. My current log-in as of yet is still relying on my front end accounts. I am a bit confused as to my log-in script now... Do i have to open the back-end file first and call the re-login script before... im just confused.

Background Info:

Login = A login layout with password and login field calling the filemaker login script.

Can be located in either back-end or front end, no real bother to me.

Please clear up my confusion guys, I know i'm a bit hopeless in this general area, but everything else is working completley smoothly, it would be a shame for me to have a mental breakdown at this point : ... hehe, at least I can say i'm an annoying 17 year old now :P.

Cheers in advance.


Link to comment
Share on other sites

I would assume, Genx, that if we had any idea how to answer you we would have. Happy belated birthday too, by the way. :wink2:

I am a bit confused as to my log-in script now... Do i have to open the back-end file first and call the re-login script before... im just confused.

If you're confused, how do you think WE feel? You've been on Forums long enough to know we need something specific. You are asking complex questions without providing any details. A picture of your graph (large enough to read) and listing the specific problem-script will get better results.

I read your post, scratched my head and decided I simply didn't have the time to wade through it. Hmmm, that must be how people feel about some of MY posts. :crazy2::giggle:


Link to comment
Share on other sites

The first file opened handles the login. But it doesn't matter which you open first if they both are set up with same accounts. Your globals can be set from either file.

Well, I doubt that gave you a birthday present, but it was the best I could do. :wink2:

[LaRetta <<-- practicing concise]

Link to comment
Share on other sites

Lol, i know it's hard to make myself clear sigh... Okay, this is my setup as clear as I can try and make it.. bear with me.

My front end is distributed individually to each client computer, it holds all GUI, scripts, no real user accounts and no tables (all TO's are referenced from the backend).

My back end is hosted on the server. It holds all the tables, and very very few scripts. One of these tables includes an accounts table that stores user details as well as a login.

Now, previously, my accounts were stored in my front-end... and my log-in script ran through the front-end, accounts were created in the front-end easily through the use of front end scripts.

Now here is where the problem arises. I need a way to create actual accounts in the back-end from the front-end.

I need to work-out how to keep the back-end data properly secured, aswell as how these login scripts are meant to run if the only accounts to exist will be kept in the back-end...

If there is anything still unclear, please feel free to yell at me, i'm open to a lot of yelling at the moment hehe.

Thanks lots


Link to comment
Share on other sites

  • 4 weeks later...

I acheived what i wanted in 5 steps...

1. Log in as low priv user in front end and execute backend script to log in as low priv user there.

2. Go To login screen in front end, allow user to attempt login (error checking etc).

3. If user succeeds in login, store account name and privilege set name into 2 global fields (or variables).

4. According to the stored privelege set, login as a privelege set user in the front end (3 main priv sets, one account for each).

5. I now have one main login system (all my script executions etc are done by referring to global fields for privelege set).

... Yay for me...


Link to comment
Share on other sites

  • 7 months later...

... Answer to this one is to have duplicate accounts in both front-end and backend with the same passwords... If you login to one file, you are granted the same access to all other files (if the passwords and logins are the same)

Link to comment
Share on other sites


I'll just stir the pot now...

I'm not sure I'd like to maintain your solution--what happens when you have to add a new account? Do you re-distribute the front end to every client user? Moreover, what about if you distribute the same solution to more than one client? How do you ship a new front end and propagate the accounts into the new front end?

Finally, I'm not entirely convinced that you even need the accounts in the front end, since (presumably) the front end is the developer's domain, and no one else needs advanced access to the file. All they need there is the ability to run scripts, view layouts, etc.

I've been digging at the same problem for a while, and am leaning (for security purposes) toward a front end that has extremely limited access, and a back end file that has preset Privilege sets and scripts for creating accounts and assigning the Privilege sets. Both files are opened with the initial limited access account; when the user chooses to edit or view real data, they are forced to re-login on the backend, using scripts to access FM's own accounts and login procedures.

Other priorities in my life have precluded my implementing this, but I don't see why it wouldn't work effectively and securely in a Separation Model situation (which is what I am working with).



Link to comment
Share on other sites

This topic is 5481 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.