Jump to content

Different Password Needs


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

Recommended Posts

  • Newbies

I am converting a single fmp 4 database that was using FMP 4, Tango, and WebStar to a fmp5 / Claris Home Page 3 solution (no more Tango or WebStar is the goal).

The problem I have is "passwording". The audience is simple: they are either the general public or employees (staff). I need the general public to be able to access their site without any password prompts, but I need the employee-only section protected by a log-in and password.

Here is where I am:

Using the same database, I have built two distinct sites: one for the public and one for the staff. However, without the directory-level security of our previous system, I am stumped on how to open one site to the public (no password) while protecting the other site with a password.

My attempts at applying the appropriate security using the Web Security Database seem to fail. I either end up with the public users needing to enter a password, or removing the protection on the Staff-only pages.

Does anyone have any ideas that would solve this within the Claris Home Page / fmp5 arena?

Thanks - Tim

Link to comment
Share on other sites

  • Newbies

I tinkered a little with the two separate databases. However, I was unsure how to pull it off.

I am fairly comfortable with traditional relationships in fmp, but was stumped trying to figure out how to build two databases that are exact mirrors of each other. Each would have to allow new records and editing to occur, yet have those changes be instantly reflected in the other.

If I was to accept the fact that fmp can only provide database level security, does anyone know how much work I lose if I switch this to Lasso (for directory level security) or try our WebStar with FileMaker's Web Server Connector?

Thanks for the suggestions so far.

Tim

Link to comment
Share on other sites

Let's see. You are publishing already and plan to convert to straight cdml, eliminating Tango. I gather we are not talking about Instant Pub.

And you are using two distinct web sites, one for all users and one for employees. (this sounds very touchy)

Set it up through web security.fp3 and your database access using passwords "all users" and "slaves".

When you start (or restart following db maintenance) your browser application, open the files through the web for all users and keep the files open. Once db files are opened for "all users" a password is no longer needed (unless you want to make your own for whatever reasons within your solution).

Since the db will be open for "all users", it will be running for "slaves". what to do? So set up a database solution for employee passwords which will require them to sign in, and incorporate that into your browser solution for "slave".

Or just use "all users" and for the employees site incorporate in a db /password solution into the db and browser. (but two sites to one db solution sounds very touchy)

Also, in conjunction with your solution, your db is best to have a layout exclusively for the web. Only the fields you want all users to access in whatever fashion should be on that layout. The fields and data they do not need to see should not be on that layout. And the same for the "slave" site. They should have their own distinct layout.

But do you want to share the "all user" application with the "slave" application? And do you plan to allow this through FMServer ('cause you don't want to try to run your web application through FMS 'cause that doesn't work). So you probably are going to need to have both FMUnlimited going into FMServer. You do understand that there are limits to how many clients per hour FMPro 5.0 can handle, unlike the unlimited number of hits which FMPro 4.0 can handle. (The upgrade which limited use, thus increasing operating costs.)

Peace

Keith M. Davie

Link to comment
Share on other sites

  • Newbies

Thanks for the replies! Let me clarify a little - this seems to be getting complicated.

We have used the dual site to one database for several years without complications. The big difference is we no longer have WebStar in the picture providing directory level security.

The two sites (public & employee) have already been built in CHP3 and work great (with the exception of the lack of an employee password requirement).

We are running fmp5 server on one Mac G4 and Unlimited on another G4. The web sites reside on the Unlimited machine.

The employees only access the database through the CHP (CDML) web pages.

Keith's idea of:

"Or just use "all users" and for the employees site incorporate in a db /password solution into the db and browser..."

sounds like something close to what I am after.

So if it is possible, how would I incorporate a password requirement on the employee site that is not on the public site - both sites linking to a single db?

Thanks - Tim

Link to comment
Share on other sites

Basically like the entry page to write this response to you. I am asked to input my name and password into the two fields. Through a verification process such as an exact search of two fields I get confirmation on submission - otherwise you would not be reading my answer.

You need to set a field in the database named id (I prefer ego) which will store the employee's password so that you can search it. You can allow the employee to make-up their password or you can assign an unique or random generated alpha-numeric.

And before you ask me about an exact search, go to

http://www.filemaker.com/support/index.html

Search and read: Article Number: 104829, and Article Number: 105687

Peace,

Keith

Link to comment
Share on other sites

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