Can't log in to a database with URL parameters with Webdirect?

[truelifeajf]

In IWP, you could specify the database, user, password... and then create your own login page within the actual hosted filemaker file.

 

I can't fine anywhere that this feature exists with Webdirect.

 

Does anyone know?

[KaosMaker]

As far as I know, there is no way to currently pass in authentication directly via URL like you could with IWP. However, if you don't mind a tiny bit of CWP, there's another thread in the WebDirect forum that does talk about possible ways to pass a parameter or even multiple parameters in, and you can use an OnFirstWindowOpen script to convert that parameter into authentication.

 

Before anyone says that such authentication is inherently insecure, that is perfectly acceptable for certain very specific uses. I would never recommend any authentication privileges with any real power be sent over URL in any form, but there are uses for a limited access account where it doesn't matter if anyone gets the authentication credentials. Basically no worse than providing an open account with no password, but with a minor filter to keep casual people out.

[William Keyte]

I occasionally speak to Kieran - the Sales Engineer Manager in the UK and he confirmed for me just before Christmas that the ability to pass the username and password to invoke automatic authentication is not now available in web direct. I did express my disappointment to him quite strongly ;-) but he did point out of course, the obvious security issues. But I agree with you, KaosMaker; there are times when this would be appropriate. Completely killed some functionality in something we're doing. Thanks for your tip above - might investigate that.

[truelifeajf]

Well I ended up just putting the database name in the URL (#dbname) and setting the database to auto-login which then goes to my own user / pass screen built in the FM solution.

[Steven H. Blackwell]

And this results in a less secure system.  WebDirect functions as it does for good reasons, as Mr. Saunders no doubt told you.

 

Consider the impact on your organization if there were a data breach and the increased level of risk of that occurrence to determine the appropriateness of what you have done here.  Take risks you understand; don't try to understand risks you take.

 

Steven

[KaosMaker]

I'm not sure I appreciate the insinuation that I or the others in this thread don't understand the risks we are taking. Opening a specific partition to the web that has NO ACCESS to any vital data is a good way to harness Filemaker's power into a long, complex form submission process. And forcing a login (or leaving the default login with a blank password, as WebDirect currently requires) is a good way to make it easily accessible to new, random users. Due to the nature of our web app, neither forcing new users to actually register, and receive actual login credentials (which would have the same limited permissions as the current blank password account), or recreating the entire collection of applications in HTML or CWP, is feasible.

 

Given the fact that even if we were handing out actual native Filemaker security logins to new users, the fact remains that we still have no idea who these people are. So our system is no less secure, because either way, unknown users are entering that partition of the system with the same (limited) access. Obviously, that means in either case, we'd still be unable to trust users with any form of access to our data, and therefore they are not.

 

So, yes, there are uses for forced logins via insecure methods. If we were dealing with trusted users, they'd have actual secure accounts, with real access to important data. But when dealing with untrusted users anyways, what does it matter?

[Wim Decorte]

I'm not sure I appreciate the insinuation that I or the others in this thread don't understand the risks we are taking. 

 

 

Easy now.  Only you know the specifics of your solution, answers here are given not knowing your knowledge / solution specific details.  So answers are always fairly broad. These threads are also read by lots of others so answers tend to always carry a message to those that goes beyond the specific answer for you.

 

A large number of FileMaker developers "stumble" into development without formal training in programming or security matters. For a lot them security is an afterthought and the security model & tools are not very well understood.  And from that comes not understanding the risks that come with choosing approach A over B.

[Lee Smith]

Nicely said. 

[Josh Ormond]

Kaos - can't express the importance of this enough. It is often we run into a topic ( Topic B ) where someone is attempting something they read in another thread ( Topic A ), and in the process of the discussion they have the realization that their confidential data has been open and exposed, because that the poster of Topic A understood the risks, the poster in Topic B did not. It's passive training thing.

 

...so answers tend to always carry a message to those that goes beyond the specific answer for you.

[truelifeajf]

I'm not sure I appreciate the insinuation that I or the others in this thread don't understand the risks we are taking.

 

 

KaosMaster, don't worry about Steven's comments too much. My opinion (and I am allowed to have an opinion about this) is that's just Steve's style. My opinion is that in any topic about security, Steven chimes in with warnings that have what I believe to be an air of superirority but lack specifics.

 

Maybe it's just me (and you)... regardless, I've tried to push Steven in another thread to provide specifics so we may be educated but I felt they're never forthcoming.

 

From what I understand I've secured my solutions quite well but am always open to specific examples of how a particular process results in a security issue.

[Wim Decorte]

My opinion ,,,

 

The main difference is that nowhere in the thread were people singled out.  And you just did by calling out Steven by name.  Twice.  Pretty bad form.

 

Anyway: in the other thread(s) that you referenced the topic of security vulnerabilities was covered extensively.  These forums are NOT the place where you will find detailed information about any existing vulnerabilities.  So if you treat this as the definitive reference you are not doing yourself a favor.

 

One thing you could do is call FMI and ask them for a reference to a few security experts if you are serious about scrutinizing your solution.

[Josh Ormond]

Steven has provided vast examples of security and FileMaker.

1. VTC - He had produced an entire course on the subject.

2. Print - I believe he also had a book at one point. Though I haven't gotten my hands on it yet.

3. Conferences - especially in this last  product conference in Chicago, he laid it out. He showed in great detail the problem, and the solutions to many issues.

 

But this is not the place to record that. Sadly not everyone looking here, has good intentions with such knowledge.

 

My opinion is that in any topic about security, Steven chimes in with warnings that have what I believe to be an air of superirority but lack specifics.

 

Maybe it's just me (and you)... regardless, I've tried to push Steven in another thread to provide specifics so we may be educated but I felt they're never forthcoming.

[carlosnorvik]

We all make security mistakes, a word of warning on a possible failure is always welcome (at least by me!)

 

In this forum I have learned and improved my applications by asking and following tips, each give in the particular style of the writer, but my guess is that at least 99.999% of the replies are sincere and in good faith.

 

I write my apps. for my company, mostly as a hobby and a stress killer.

 

Have a great weekend.

[William Keyte]

Gosh - I've only just returned to this thread and hadn't realised how much people had written - not least the slightly patronising response to my earlier post ;-) Nothing personal, I'm sure.

 

Thank you KaosMaker for your supportive points you made so well. I also agree with you Wim, about broader points and people not knowing the specifics of a solution.

 

I think there will always be a place for a force-login and it depends upon how you handle it. In another thread I had explained that I had built a system of mirrored alias accounts that expire automatically. In addition we were also using SSL etc. Steven, I do take your point about security and having been developing in Filemaker (and in other technologies) for a good 20 years this was obviously not lost on me. Having said that, it was functionality that was there before that has now been removed which could upset the apple cart for many, I would think. I would have been happy if they'd at least included the ability to pass parameters - but no matter; this can be achieved other ways ;-)

 

Blessings to all

 

Will

[dwjones]

I have a small, simple document management system that enables staff and students to search for topics of interest via IWP and now Webdirect - there is nothing particularly sensitive about the information, but there is no need for students to view information of no relevance to them. I controlled the staff versus student access via two different URL login parameters - students have a link from their intranet page that gave them a filtered view of the records while staff have a link on their intranet page that gave them full access to all records.

 

These may be alternatives:

• user authenticated login, but for the users this adds an unnecessary extra step in accessing the database, when basically all they need is quick guest access.

• Guest login then ask the use to choose their group.

• split the system into student and staff e.g. have a common data file with two separate interface files, one for staff and the other for students - messy.

• start with Guest access and mark those records that are staff only. When a user clicks a staff record, authentication is forced, and if the user is in the staff group, access is allowed.

 

Can anyone make other suggestions about alternatives in Webdirect?

 

Thanks

David

 

PS. removal of this functionality is really annoying and I just trust that FM had good technical reasons for doing it.

[truelifeajf]

Hi David,

 

With IWP, I'm guessing each URL had a different username so your script could use get(username) to determine whether to show a "filtered" list of records, or the full list of records.

 

If that's the case, then given your database can't know which user is logged in as WebDirect URLs don't support that, you could work out what Layout is in the URL - which is something WebDirect does support:

 

1. Set the database to auto login using whatever user you want

2. Make sure you have two layouts - one for students, one for staff

2. Put the database name, layout name and record number in the URL:

 

/fmi/webd#<database>&lay=<layout name>&viewstyle=<form/list>&record=<record number>&mode=<browse/find>

 

3. Set a script trigger on each of your two possible "landing" layouts so when it loads, it can set a global variable / field to indicate which layout was the entry point. If you specified "my layout - students" in the URL then the database will end up on that layout and therefore know what "user type" you're dealing with.

 

Hope that makes sense. Basically using a layout name to delineate between user types, rather than using separate user accounts.

[john renfrew]

I have a use case I would like to employ in a FMP13 solution I am near finishing for a client, which involves yearly re-ordering.

 

I can see that creating a separate file which auto-logs on will work but would like the user to click a link which includes a parameter to then take them to 'their' record, so they ca confirm quantity and colour etc.etc. When order is complete idea would be to run script on Server to create 'real' record (were it not for the other bug about authentication)

 

That DOES seem like a perfect use for WebDirect. Most people are used to clicking a personalised link NOT having to manually enter a code into a search box to then forward to the correct record.

[truelifeajf]

I tried to search the forums for a thread talking about a way around this by using PHP publishing. The URL points to a PHP page which extracts the variables from the URL, inserts them into the database and  then redirects to the Web Direct login... something like that. But I just can not seem to find that thread, sorry.

 

But you could use the same thing I mentioned above... specify a LAYOUT in the URL (you'd need a separate, blank layout for EACH customer). One they're on that layout, a script trigger would immediately run, knowing the current layout and therefore knowing which client it's for.

[KaosMaker]

I believe the thread you are looking for is here:

 

http://fmforums.com/forum/topic/90331-can-you-easily-pass-a-parameter-to-a-webdirect-solution/

 

The Layout-as-parameter solution is also useful, if you have a limited number of possible parameters (and therefore layouts). When you have many layouts, it starts getting difficult to maintain.

 

So long as there is no hazard to improper access, this is fine (for example, ours is used to decide which form process to initiate. If they deliberately try to hack the URL parameters, they'll just get a different form process, at worst, and no harm done besides a waste of their time). Naturally, make sure you restrict the security permissions to the necessary tasks.

[Josh Ormond]

WebDirect will allow you to go to a specific record. ( format of URL: http://<IP address>:<Port number>/fmi/webd#<database name>&lay=<layout name>&viewstyle=<view>&record=<record number>&mode=<mode> )

 

And if the guest access is enabled, seems like you should be able to get them to that record without logging in. If that works, I would do it indirectly so that someone can't guess the url and go to other records. But you could at that point use the relogin step to force the user to login. Though I'm just getting over being sick, so I may have missed an important thought with what you are doing, or with how WD actually works.

 

I can see that creating a separate file which auto-logs on will work but would like the user to click a link which includes a parameter to then take them to 'their' record, so they ca confirm quantity and colour etc.etc. When order is complete idea would be to run script on Server to create 'real' record (were it not for the other bug about authentication)

 

That DOES seem like a perfect use for WebDirect. Most people are used to clicking a personalised link NOT having to manually enter a code into a search box to then forward to the correct record.

[KaosMaker]

No, you don't seem to have missed anything. The only thing to note is that record number is not necessarily permanent (if any records get deleted, for instance).

 

So for example, to address both the fluidity of record numbers and to produce an indirect URL, here's our solution:

 

For each record, have a field that contains a random, unique, but NOT serialized code (e.g. f3m913k)

In the same table, make a global number field (e.g. gRecordNum).

Provide users with the a URL to a php page with that code (e.g. www.xyz.com/login.php?c=f3m913k)

Have the php page pass that code into a script via CWP that finds the matching record, shows all, sets the global field with the appropriate record number, and returns the matching record (show all is important to get the full-table record number, and returning back to a single record just saves you from transmitting the whole found set back to php)

Have the php page launch your WebDirect page with the global number field (gRecordNum) inserted into the URL in the appropriate spot.

 

NOTE: WebDirect ALWAYS loads the first record of a table first, THEN goes to the appropriate record as defined by record number. So if you have any onRecordLoad scripts, make sure it bypasses record 1 (and that record 1 is also blank or otherwise unimportant).

 

If you absolutely do not want people to see other records, this isn't secure enough, given that someone could easily just type in any old record number in your WebDirect URL. But if you don't care, this should be adequate. In addition, using php and iframes, you can keep users from even seeing your WebDirect URL in the address bar, but again that is just an obfuscation measure to avoid casual attacks, not actual security in any form.

[dwjones]

 

/fmi/webd#<database>&lay=<layout name>&viewstyle=<form/list>&record=<record number>&mode=<browse/find>

 

Thank you truelifeajf. This should do the job nicely. I just needed to think more laterally (or deviously).

David

[jeffwhorton]

This is my login page for when using FMS v11 (IWP), how do i change this to work with WEBD?

 

The X.X.X.X is obviously my IP Address.

 

 

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 

<html>

 

 

<head>

 

 

<title>Mudpie Product Inventory</title>

 

 

<BODY>

 

 

<img src="http://X.X.X.X/MudpieProdInv/images/logo.gif">

 

<form action="http://X.X.X.X/fmi/iwp/cgi" method="get">

 

<input type="hidden" name="dbpath" value="/fmi/iwp/cgi?-db=Mudpie%20Product%20Inv&-startsession">

<input type="hidden" name="acct" value="account">

 

<input type="hidden" name="-authdb">

<label>Account</label><br />

 

<input type="text" name="name"><br />

<label>Password</label><br />

<input type="password" name="password"><br />

<input type="submit" name="login" value="Login">

</form>

 

 

</BODY>

 

 

</HTML>

[dwjones]

Hi David,

 

With IWP, I'm guessing each URL had a different username so your script could use get(username) to determine whether to show a "filtered" list of records, or the full list of records.

 

If that's the case, then given your database can't know which user is logged in as WebDirect URLs don't support that, you could work out what Layout is in the URL - which is something WebDirect does support:

 

1. Set the database to auto login using whatever user you want

2. Make sure you have two layouts - one for students, one for staff

2. Put the database name, layout name and record number in the URL:

 

/fmi/webd#<database>&lay=<layout name>&viewstyle=<form/list>&record=<record number>&mode=<browse/find>

 

3. Set a script trigger on each of your two possible "landing" layouts so when it loads, it can set a global variable / field to indicate which layout was the entry point. If you specified "my layout - students" in the URL then the database will end up on that layout and therefore know what "user type" you're dealing with.

 

Hope that makes sense. Basically using a layout name to delineate between user types, rather than using separate user accounts.

Thank you truelifeajf, that's a good solution.

Regards

David