Meta Refresh and Location Directive not Equal??

[proton]

Hello people,

Part of my website is used to login to a database. I wanted the login to be automatic so I used the automatic login syntax:

http://username assword@webaddress/filemaker info

since I didn't want the user to have much input in this I set it to operate automatically by putting it on a page by itself in a meta refresh tag. So the user puts in some info, submits it and it takes them to this page which automatically logs in into the database and also automatically redirects them to another page.

Now as it is known the meta refresh is not as good as the location directive used in the FMP-Header tag. For one, even if you set the time value to 0 there is still some time delay. Whereas with the Location directive the redirection is almost instantaneous. So I used the following structure:

[FMP-Header]

HTTP/1.0 302 Moved Temporary

Location: http://username assword@webaddress/filemaker info

[/FMP-Header]

The http://... info is exactly the same as in the meta refresh I used previously. With the meta refresh it works like a charm, but when I use the Location Directive the filemaker login box automatically pops up. It shouldn't do this because the information in the tag is doing the logging in so I shouldn't see any dialog box. And it affects other stuff. With the meta refresh it goes through the login smoothly. Now you know once you log in to one database and another database has the same password it will not prompt you to enter that password in the other database. When I use the meta refresh and go to the second database (which has the same password) it just opens and all is fine. When I use the Location Directive and the dialog box pops (which it shouldn't) and I enter the username and password, when it goes to the next database it pops up a login dialog box again!

What could be the cause of this? Hope ya'll can help me. Thanks in advance.

[Vaughan]

Not what you want to hear... Embedding usernames/passwords into urls is NOT secure. If the password allows create/edit/delete privileges, it's like leaving your front door key under the mat!

Why not set the system up right: get the Web Security databases happening. If the users need a password they'll get used to typing it in. If they don't need a password then configure Web Security to have a "all users" for that database so they won't be asked. Don't go embedding the password into a plain-text url.

My advice: if the database allows edit and delete access then it needs a password.

[Keith M. Davie]

proton,

Thanks for your query. I have not tried this before so it gave me an opportunity to experiment. Frankly the tag looks like it would be useful. I experimented with the fmp-header tag and have had no success. The best result I could get was a FMP generated page to allow the client direct access to the db files, which is something which is not desired. However, the db's with which I experimented have no pword restrictions other than those allowed for all users in Web Security. The majority of messages were that anything which I addened to the address 198.0.0.1 (my fake lan) returned a message that the file was not found. Clearly I am not understanding the syntax of the fmp-header.

While the cdml ref. suggests that one could redirect to a different http server (http is not case specific), the example presented is not to a different server, per se, but to FileMaker's (the example presenter's) www.default page. Hardly a stellar example of the possibility the presenter implies.

I went to www.w3c.org and clicked their HTTP link. I located the document RFC 2068 which is referenced in the tag discussion of cdml reference. It is a 160+ page document about a core construct, but well beyond my interpretations.

On the other hand, I agree with Vaughan's advice to you, for that was my first thought as well.

[proton]

quote:

---

Originally posted by Vaughan:

Not what you want to hear... Embedding usernames/passwords into urls is NOT secure. If the password allows create/edit/delete privileges, it's like leaving your front door key under the mat!

Why not set the system up right: get the Web Security databases happening. If the users need a password they'll get used to typing it in. If they don't need a password then configure Web Security to have a "all users" for that database so they won't be asked. Don't go embedding the password into a plain-text url.

My advice: if the database allows edit and delete access then it needs a password.

---

Vaughan,

Thanks for your advice, but the password doesn't allow create/edit/delete privileges. It's for Browse. For various reasons I can not use the Web Security database so I used Filemaker Access Privileges and designed a custom login solution.

The password only has browse privileges so I'm not really worried about users getting it. But as a precaution I put it on a meta refresh page as I stated.

The master password allows editing and deleting but that is not posted anywhere, so I'm not too worried about that. Thanks for your quick and concerned reply though.

[proton]

quote:

---

Originally posted by Keith M. Davie:

proton,

Thanks for your query. I have not tried this before so it gave me an opportunity to experiment. Frankly the tag looks like it would be useful. I experimented with the fmp-header tag and have had no success. The best result I could get was a FMP generated page to allow the client direct access to the db files, which is something which is not desired. However, the db's with which I experimented have no pword restrictions other than those allowed for all users in Web Security. The majority of messages were that anything which I addened to the address 198.0.0.1 (my fake lan) returned a message that the file was not found. Clearly I am not understanding the syntax of the fmp-header.

While the cdml ref. suggests that one could redirect to a different http server (http is not case specific), the example presented is not to a different server, per se, but to FileMaker's (the example presenter's)

www.default

page. Hardly a stellar example of the possibility the presenter implies.

I went to

www.w3c.org

and clicked their HTTP link. I located the document RFC 2068 which is referenced in the tag discussion of cdml reference. It is a 160+ page document about a core construct, but well beyond my interpretations.

On the other hand, I agree with Vaughan's advice to you, for that was my first thought as well.

---

Keith,

Thanks as well for your thoughts on the matter. There's another list that I belong to, and a guy there had a fine example of the redirect using the FMP Header tag.

The address for the example is:

http://www.sawco.com:591/a/redirect/

Hope this helps you Keith. Again thanks to you and Vaughan for your thoughts.

P.S. His base address http://www.sawco.com:591 has a number of examples on all the CDML tags, along with simple descriptions for each one.

[ September 10, 2001: Message edited by: proton ]

[Keith M. Davie]

proton,

Thanks for the info. I clicked the first link .../a/redirect. An interesting example in that the client creates a token which is then used in the redirect. First I punchend in the link itself and was returned to the same page awaiting a new http:// entry. So thien I punched in www.fileville.com and got the home page for FileVille. Clicked Back and entered the second link http://www.sawco.com:591. Got the message that the document contained no data. Then I clicked the same link from your message and got the same no data message, so that link must have an error.

The point is that this allowed a redirect by the client establishing the token which is used with the fmp-header redirect. Clearly the link must be accurate. Have you tried your redirect through the use of a token as in this example?

As to the use of the password in the meta refresh, once the password (and whatever other criteria might be required) has been recognized through the database file, a different unique id field could be captured and used in lieu of the password. The password needs not be displayed.

[Vaughan]

proton

My point is that you have set up a password for browse, then give people the password when they want to enter. What's the point, it's no security at all.

Now that I think of it, it must be a pasword for browse+export, since Web Companion requires export to operate.

[Tyfud]

Try using some javascripting. Wouldn't take much, just enough to submit the password and then click a submission button.

use the on Load="top.location.href='http://username assword@fmpro'" (I had to put a space in the "on Load" due to message board limits)

then on that page, have a form submission button (could be a white image with the -view tag on a white background) which when the body loads you do another on Load="document.form.buttonname.click()"

Hope this helps.