Security DB Login

[Garry Claridge]

Does anybody know of a way of embedding the Web Security Database login panel into a web page. That is, so it does not pop-up when the user attempts to access the database, it is however presented in a controlled and aesthetic manner.

Thanks

Garry

[Keith M. Davie]

Huh?

What version of FMPro are you using?

Are you using Instant Publishing?

What books have you read?

[ August 25, 2001: Message edited by: Keith M. Davie ]

[Garry Claridge]

Version of FMP is 5.5 for development and 5.0 Unlimited for serving.

Using Custom web-publishing.

Books in relation to CDML are:

"Database Publishing on the Web" - Maria Langer

Developer Guide Chapter 9 "Custom Web Publishing using CDML"

"web_security_tips.pdf" from FMP web-site

"Web Security.pdf" from Web Securit folder in FMP application folder.

I am using the "Web Security" database for one of the applications I am building. I don't want to use the "All Users" group for this application. Hence I am using particular user names and passwords for controlled access. What I am trying avoid is the "pop-up" login screen generated by the "Web Security" database; I would like to be able to embed this "login" into a web-page for aesthetic reasons.

Perhaps I have missed something in my reading?

Thanks

Garry

[ August 26, 2001: Message edited by: garrycl ]

[Vaughan]

Authentication is handled by the browser.

Authentication is requested whenever the user attempts to do anything that is protected by a password. Users won't need to authenticate for any privileges specified by the "all users" record in each database in Web Security.

As far as producing your own, you can't really. Not unless you want real security: anything else that you make will be easy to hack around.

You can avoid the authentication by embedding the username and password in the url, but this is equivilent to leaving the key in the door lock when you leave the house.

If you want security, real security, then users need to authenticate.

[Keith M. Davie]

One option could be building your own authentication using passwords, user-names and scripts. Of course, you will need a workaround for the script problem on the multi-user web. But I know of one. That said, a field can be constructed within a database which presents boolean response possibilities (0,1) for access purposes. That can then be handled by an [fmp-if] conditional on the format page which can be used for directional purposes. I know whereof I speak.

[Garry Claridge]

I have recently built another application where we use our own logins, audit trails and security. These work very well. However, I have just discovered the -fmp_xml and -raw parameters. (Thanks to another topic discussion on this forum.)

So for this particular application, which has read sensitive data such as names, addresses and credit card details, we need the Web Security database. We have over 7,000 users. Our only hassle is the aesthetics of it. I have to work to graphics people for this project ;-)

As Vaughan said I may have to embed the username and password in the URL, however we will have to weigh-up the security disadvantages of this.

Thanks

Garry

[Vaughan]

The challenge with many of the diy login systems is that a cluey user can simply work around them by submitting a url directly to the database from another page, and there is no way to stop it. Download the format file, work it out, submit a modified version.

Sure, there are ways to prevent peole from cracking the format files (frames, inlines, etc -- just ask Anatoli) but they are not 100% and it's a lot of work. A lot of work for security that's not as good as browser generated authentication.

[Keith M. Davie]

"The challenge with many of the diy login systems is that a cluey user can simply work around them by submitting a url directly to the database from another page, and there is no way to stop it."

Simple and secure solution.

Scripts which move the data through multiple db files in conjunction with meta refresh of format files. When done intelligently there is no simple work around for the cluey user who would submit urls directly. The record containing the data they have written the url for may no longer exist.

I have an example I would like to share with you, I just don't have the resources to do so. Too bad.

Tell your boss to pay you for the next six months while you figure out how to run scripts successfully. It can be done.

[Garry Claridge]

Keith said:

Scripts which move the data through multiple db files in conjunction with meta refresh of format files. When done intelligently there is no simple work around for the cluey user who would submit urls directly. The record containing the data they have written the url for may no longer exist.

One of the applications I have developed uses a script to copy a field, from a non-shared file to a file which has WebCompanion Sharing "on". This shared file has only one data field, the key (item_id), all other fields are claculated relationships to the main prices file. All other files do not have WebCompanion Sharing "on".

The script is run by a button on the main prices database which asks the user (staff on the LAN) to "Change Internet Access". If it needs to change to "yes" the script copies the item_id to the prices_web file; if the change is to "no" the script deletes the related record from the prices_web file.

Using this script method, this application only exposes a file with just the public pricing information. Hence, any attempts to see "mark-up" and supplier prices etc by using -fmp_xml and -raw are not possible.

However, for the application for which I have the Web Security db login aesthetics question, this is not possible.

Thanks.

Garry

[Vaughan]

All of these solutions are still no match for the authentication that Web Security database offers.

Whatever happened to SIMPLIFY? <grin>

Regarding scripts not running well over the web: my first task is to determine that there actually *is* a problem. The second task is to solve it!

[Keith M. Davie]

Vaughn writes, "Regarding scripts not running well over the web: my first task is to determine that there actually *is* a problem. The second task is to solve it!"

The problem can be realized only when you have successfully managed to make two (or more) near-simultaneous calls upon one or more script tags. I have done that many many many times.

Have you done that Vaughn?

What did you than identify as the problem? Or was there none?

[Vaughan]

Wow Keith, very fast response! Here in Australia it's 10:30am, I have a feeling you must be burining the midnight oil a bit over there!

To be honest I haven't done anything at all yet. I was merely stating what I will do when I get around to doing it. I have got a couple of sites that use a script or two ver the web and have had no problems so far, but then again ther are not used often. So far I've been 1) skeptical that there is a problem at all; and 2) very open to the possibility thatZ