Force password prompt on secondary links?

[ibiubu]

Once a user is prompted for a password and then they enter the web site containing the information from the FileMaker database, any subsiquent links that stay within that same string no longer require a password.

Is there anyway on a subsiquent link to FORCE a password prompt to take place again even though under normal circumstances it would not be required?

The subsiquent link looks something like:

http://63.226.000.000/FMRes/[email protected]&-layID=1&-max=1&-format=formvwcss.htm&-mode=browse&-findall

[ibiubu]

Well, there would be a reason I have not been able to get this one to work. As stated in a FileMaker document...

IMPORTANT NOTE: If you have another link on your web page that requires a different password, you cannot simply click the link and enter the password. You will have to close the browser completely and relaunch. This is a limitation in FileMaker Pro and Web Companion.

[Vaughan]

Sorry, I've got to disagree here. This password business is a limitation with Web browsers. Got nothing to do with FMP or WC.

I cannot see how embedding userid and password as plain text into a web page can be remotely be considered security. It's leaving the keys under the mat outside the front door.

[ibiubu]

If anyone is interested...here is the solution I came up with.

Senario: 3 links on a page.

1) Link 1 includes a username and password embeded in the link. These are set with access priveledges for browsing only. No password prompt is required with this link.

http://username:[email protected]/FMPro?-op=equals&-lay=CGI&[email protected]&-error=errors.htm&User=&-find=Submit&-format=Summary.htm&-max=25

2) Link 2 is for data entry. This link uses different access privledges than the first link. The problem here is that if someone clicks link 1 first, then a username and password has already been entered for them. If they come back and click link 2, there is no way to force the password prompt to come up forcing them to enter a different password.

Slotion for link 2. Include username and passord (see link 1 sample) information in this link as well. use a different username and password than link 1 with access privledges that allow editing of records. This of course still leaves this link unprotected. I then used Adobe Golive to add a password javascript to the link. Any time this link is clicked on, a password prompt comes up. The password is entered and then the user is passed on to the database using the embeded filemaker username and password with the appropriate privledges.

3) Link 3 is administration access. I followed the same steps as for link 2. Used a different password javascript for this link and included the appropriate filemaker username and password in the link for administrative access privledges.

All in all it may not be the most sophisticated solution...but given the restraints for this scenario presented by filemaker...it works.

LR

[ibiubu]

You are correct on the point of the limitation of the passwords I stated it incorrectly. It is the limitation of the web browser. Once the password is entered there is no way to flush it out of the browser without quitting and trying again.

On the other point I disagree. The only password information obtainable is the one with the guest browse only privledges...no big deal.

The other two links are first protected by the javascript password created in GoLive. Only if this password is known and entered when prompted is the user passed to a second blank page with a redirect script that includes the FileMaker administrative username and password that links to the database using those access privledges.

If the user does not know the javascript password, there is no way they are given access to the second page containing the administrative username and password. The Golive password is encrypted. There is no indication in the html code what that password is or to what new page it links. This makes the links using this method secure, even though they include the FileMaker username and password.

LR

[Vaughan]

Ahhh, but if I am given the javascript password, I can easily discover the real FMP database password.

Not to criticise your system -- I genuinely think it sounds like a good solution -- just highlighting the security issues with embedding passwords in urls or web pages.

[ibiubu]

Again this is a very good point...and true. But actually anyone accessing this prompt knows the FileMaker password. The password for the javascript access is the same one for the FileMaker privledges. In reality I wish under the circumstancs I could force the prompt to come up and ask for the FileMaker password. Then I would have no need to use the password through javascript.

The javascript is not really meant to replace the FileMaker password, but under this scenario since I can't force the FileMaker prompt, this is the next best thing to mimic it.

LR

[Keith M. Davie]

What happens if you refuse to use FMPro's pop-up window? To avoid this you set Web Security for All Users and use no password. Let's face it, that pop-up lacks elegance.

When you come to my site if you choose to register here is what happens. You register, via a web page I have provided, and the data you provide goes into a db file which uses the protocol I have established.. You then submit your unique password and the data is removed to at least two other db files. The record which was created by the cdml tags is then deleted. There is nothing left to access.

All the sensitive data one wants to remove can be removed in this way. For instance at my site when you register, your first name and last name and password are removed to a file which is not accessed by Web Companion. Your username is put into a file which is accessed by Web Companion along with at least one unique identifier, not your password.

After you are registered if you go to another link you are asked to submit your username and password. This is a lot like registering at eBay. When you want to bid or place something for sale, you must sign in with your username and password. At my site, when everything is confirmed it is done so in the FileMaker database files I created, not through the FMP protocols.

There are many ways to develop such a solution. I use scripts safely and effectively because I know how to do so in a browser solution. The script to move data and delete the original record can be structured to take less than 100 milliseconds. As structured for my site it intentionally is run for a longer time.

Quite frankly, you could be forced to submit your username and password at every page following registration. And thereafter I could control what you read and what links are available to you primarilly through the intelligent use of the fmp-if conditional. It is simply a matter of design.