Jump to content

WebDirect login accounts


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

Recommended Posts

I've been researching how people handle logins for WebDirect and my head is swimming with contradictory information.

On my existing website I have 1,775 users. Their account information is stored in a mySQL database. The account information is little more than username, password, company name, and real name.

For the new WebDirect site, I was originally planning to autologin to the file using an account that only had access to the login screen. Then, use custom dialogue to allow the username and password to be entered. I'd use the username as a relationship between the global and the users table, check that the password matches, then do a relogin to a generic user account that has normal view/edit privileges.

But then I read that you're not supposed to "bypass" FileMaker security. I'm not sure if that counts as bypassing.

Then I figured I'd use a script to step through the existing users table and create accounts in the database for all 1,775 users. But then I read that some people had problems with files that had more than 1,000 user accounts.

So, now I don't know what to do. We're not storing credit card information so it doesn't have to be Ft Knox secure but I don't know what direction to go in. I feel like my first option is good enough but wanted to see what some of you thought.

We do have a SSL certificate for the web server.

Thanks,

Link to comment
Share on other sites

This is not the intention for Web Direct. How many concurrent connections do you have? Only that many could access the site at one time and depending on the complexity of the solution if all users are online in addition to local or WAN FMP connections the performance may not be ideal.

Not to mention the managing of the vetting and onboarding process or a way to manage forgotten or request to reset passwords.

Alternatively you could use Active Directory / Open Directory and store the user credentials and accounts and groups there and then authenticate with external authentication.

one possibility is to create some PHP pages for all the account management which uses the filemaker API and can create records in a user table and then a call to a server side script that will create an account then show a result for the user to click a link to redirect them to the WD login page.

There isn't a URL string you can pass that contains the username and password -  as you can with the FMPURL

 

 

 

Link to comment
Share on other sites

That many don't access the site at once. Just that many have logins. Many of them would only go on once or twice a year and most only once a week max.

We won't be using Active Directory and probably not Open Directory.

We manage creation of accounts because they have to be approved.

My question, really, is whether my planned course of action of auto-logging in with a low-access account and then validating login credentials via a FM user table and then script a re-login using those credentials is sufficiently secure for my purposes.

Link to comment
Share on other sites

1 hour ago, Cable said:

My question, really, is whether my planned course of action of auto-logging in with a low-access account and then validating login credentials via a FM user table and then script a re-login using those credentials is sufficiently secure for my purposes.

It almost never is... mostly because it stores security info as pure data and bypasses the true security layer that FM offers.

Link to comment
Share on other sites

it is not a best practice to auto log in even with a extremely limited account that has to validate against a data table in the database via scripted means. 

Only using the built in Accounts & Privileges or external authentication, is the only recommended means to authenticate a user. Anything else is an ersatz security model, and increases your risk and becomes a threat vector in your security model.

 

 

 

Link to comment
Share on other sites

Fair enough but that is referring to a regular FM database not one accessed via WebDirect. Interestingly, part of the security is that once someone successfully logs in, they can only view records related to that particular login. So, even if someone were to find a way to force a relogin in WebDirect and access one of the accounts, only data for that one account is available. Unless I'm missing something. There are no admin accounts to access via that method. Flag fields aren't used. So, I'm not so sure Steven's post is relevant to this case.

Let's say it is, though. What about the second option of creating a separate FileMaker account for each user. Can a file have upwards of 1700 user accounts without a problem?

Link to comment
Share on other sites

Quote

Can a file have upwards of 1700 user accounts without a problem?

Yes it can.  I once made one for demonstration purposes that had 10,000 Accounts in it.  It takes a while to open Manage Security with that many.

I do recommend that you take a second look at using  External Server Authentication. it is design specifically for the scenario you describe.  You can use a Domain Controller or use Local Security Groups and Accounts on the server machine at the OS level.

Use the tools FileMaker, Inc. gives you. Don't try to invent your own.  Pay close attention to what Wim and Ocean West said.

 

Steven

Link to comment
Share on other sites

This topic is 2919 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.