CWP question

[colinkeefe]

Hi folks,

I have a client that has a bunch of proprietary data that they want to sell access to over the web. Currently that data lives in Filemaker.

The client would like to permit users to purchase access to the database, and receive dynamically generated username/password combos immediately on purchase.

We're exploring the possibility of serving this up using FMS7 Advanced, and one of my main conceptual stumbling blocks (aside from not having a copy of FMS7 Advanced) is figuring out how I can deliver on the dynamic username/password combo without some sort of human intervention every time a sale is made.

Has anybody dealt with this kind of request? It seems a common and obvious problem, but I can't think how to go about it in FM.

My question isn't so much about the cc transaction - I've done that before. I'm more concerned about:

1. generating the username/pass without human intervention (in the form of, "hey, someone bought access - Joey, go give him some user/pass authentication" and Joey then goes into the database and creates a new internally authenticated user/pass - the client would naturally prefer to avoid this!).

2. Generating a username/pass in such a way that doesn't create security holes.

I could see maybe kludging something with the Web Security Database in FM6 (though I wouldn't be happy about it). But I'm not even sure if there's an equivalent present in FS7 Advanced architecture, never mind what the best practices should be for 7 Advanced security-wise.

Simplifed, here's the workflow:

1. Customer purchases access to database (may be tiered) online via whatever method - merchant account provider or whatever

2. Username/Password authentication record is generated and delivered to user (via email preferably)

3. User logs in to database

So, questions:

Is it possible to use FM7's native security protocol for this purpose - by scripting it, or other means? If it is, it would seem a strange thing to be able to control via scripting.

Is it's possible, is it advisable?

If it isn't possible, can you suggest any FM-native methods for working around this that would still be secure? A user profile table? Plugins?

I may end up going with MySQL/PHP or MySQL/Lasso and just update MySQL periodically with Filemaker data (thereby handing off most of this headache to a subcontractor). But the client wants to know if this can all be handled with FM-native functionality.

Thanks for the help,

Colin

[Garry Claridge]

When a new record is created, i.e. a new Customer, you can use a Calculated field to generate a password/username combination. These would be returned when the record is created, you can either display it on the page or use a Script (or php) to email it.

I would have the passwords/usernames stored in the database. You can make that database table as secure as you need.

All the best.

Garry

[colinkeefe]

Garry,

So you're saying just roll my own security - fine. I guess I'm still confused though. It sounds like the generated user/pass you suggest has nothing to do with FM's own password architecture - it's just two fields in a table.

My question is, how does this generated user/pass help a user get into a database that has conventional security measures built in? i.e., if the database has:

accountname/pass

joe/shmoe

sam/smith

lenny/bruce

as existing accounts with appropriate privilege sets,

how does giving a user

field 1 value/field 2 value

from a second database help any if the first database only permits access to a valid account (joe/schmoe, etc)?

I understand that the purchased user/pass described above could be authenticated by some external process (PHP or whatever) and then the database opened with some default account set up. But the client wants to determine if this can be done with no external authentication processes:

- all username/passwords generated by Filemaker as valid internally authenticated Accounts

- all authentication passing through Filemaker authentication protocols.

If it ain't possible, that's cool. Just need to be able to say that to the client and know it's true.

Thanks Garry,

Colin

[Garry Claridge]

Colin,

I guess to be totally independent of other technologies, a Script can be used to create a new Account and to set passwords. These could then be emailed (via the Script) to the customer.

Using Scripts via the WebCompanion, in eariler versions of FM, has been restrictive because of the single thread processing. Hence, the possibility of collisions in running the Script. I hope that FM7 has alleviated this problem.

The Script should be able to be run from the Web in FM7; as it is with eariler versions.

All the best.

Garry

[colinkeefe]

Okay, I guess I'm being a moron. I just noticed that the Add Account script step is web-capable, which answers my question.

The site will not be incredibly high-traffic, so I don't anticipate problems, esp. with multithreading.

Thanks, Garry!

[Steve T.]

Hi, Colin! Glad to hear you can get what you need. I had to abandon FM for something similar because I could not restrict users to their own records. I also did not know/have that Add Account feature so I had created a duplicate copy of the Web Security Database and shuttled data from my pending db to the real Web Security Database via a script.

Why not let your users choose their own logins, though? You could set parameters and check for duplication. I guess if you're worried about security, you can create passwords for them, but I'd probably suggest letting them choose their own passwords as well.

I suppose it all depends on what you're doing, though, eh? And you should know what's best... nevermind me.

--ST

[colinkeefe]

Well, yeah, they'll be able to choose their own username - assume no dupes, a password will be auto-generated and emailed to them. This all will probably happen after they've paid for access, so I don't think there will be too much junk data.

They can change the pass after, shouldn't be too difficult to build an interface for that too.

Though if anyone can think of real obvious reasons I shouldn't be using the web-enabled Add Account, Change/Reset Password etc script steps for this purpose, please let me know.

Colin

[RobR]

Along these lines, I'd like to put a "members only" page on my site, which only subscribers can enter. Nothing too elaborate: just a login/password form on a page currently setup to allow multivariable searches of an FMP database. I checked into FM's "Web Security" database, but I do not think it will suit my purposes since I want to continue to allow non-subscribers limited search access to the database. Ideally the login/password entry would be in a drop-down menu and would allow the user's computer to "remember" the password. Login/passwords will have to be unique, so there will need to be a database associated with it. Human intervention is OK, tho a "forgot password?" emailer would be great.

Wondering if this can be accomplish in FMP or if I should try a PHP script or something. Anyone know of a good "canned" script for login/password I could drop into the page?

[Steve T.]

Hi, RR! What I had used was WSD with limited access for no password and then I forced a false -edit to prompt for a login window to have users login for more access. To "remember" passwords, you'll probably have to look into working with cookies (fmp or javascript). You could probably also fake it with simple field values (globals or relational) and IF statements, though.

Outside FMFORUMS sample files, I don't know of any pre-made stuff for FM web publishing. FM has some stuff but it tends to only be for the latest version of FM.

--ST

[Keith M. Davie]

Re: "Using Scripts via the WebCompanion, in eariler versions of FM, has been restrictive because of the single thread processing. ... I hope that FM7 has alleviated this problem."

While "hope" is a wonderful thing, consider that FMP7 is regressive regarding CWP. CDML is passe in 7. Consider the stated position of FMI regarding db / web capability and corporate (profit) goals. If you are using 7 you have an obligation to find out if ScriptMaker is still single-threaded (odds are extremely high that it continues to be single-threaded), ask FMI.

If your site will not be "incredibly high-traffic", then the chance of an event conflict will be greatly reduced. Of course, "greatly reduced" is not "problem free". So if you plan to use ScriptMaker you will need to test the solution rigorously with multiple, near-simultaneous requests. ScriptMaker event failures are not recognized by CDML (or Web Companion) and if one occurs, that client will be misinformed of the event failure.

I like to point out that a capable developer can develop a solution which allows the successful use of ScriptMaker on the web in a "high-traffic" environment. I know, I have done what you guys are asking about and I was a novice when I did it. No I do not give that answer away, it has cost me too much. And no, it is no longer for sale; trying to sell it cost too much as well. So let your employer pay you to work it out. It can be done in less than six months of concentrated, uninterrupted devotion to the solution. And there is much more information available now than when I figured it out four years ago. And if your employer will foot that bill, ask him/her if you can give away the solution when you develop it.

ScriptMaker is very do-able with CDML. ScriptMaker is excellent for web security (removing the most privileged data completely from web access). Good luck.

[RobR]

Steve -- Thanks for the interesting tip. How do you trigger the false "-edit" tho?

I have a home page that uses javascript to initiate on automatic ("onload") search of the database, which then displays some information. Then, if the web user wants to enter his own search parameters, he must browse to the search page. There, I would like him to be required to input a user/password before being permitted to run the search.

Thanks!

[RobR]

Steve -- Can you post how you trigger this "false -edit"? It sounds exactly like what I need.

Thanks! RR