It breaks the security.
1 of 1 people found this helpful
Unfortunately you're not going to be able to pass anything other than the file name with the current Web Direct rev. Credentials will never be allowed, but is is possbile that relevant record and layout can reappear in a future rev, but I doubt it.
Thanks for quick answers.
So basically what I need to do is something like:
A user login normal way, and then they see a layout with "Alerts" and where each alert can represent a link to the relevant customer record.
Or are there any better way to solve this?
1 of 1 people found this helpful
I think theres no way for an AutoLogin in WebDirect. Because it can be an big security issue.
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.
I hope it helps.
Additional parameters beyond the name of the file have been deprecated since the latest update.
Thanks a lot, this approach seems to work for my requirements.
I am having the same problem. I have server 13 v2 and passing anything beyond the name of the file does not work. The Layout Name and the record number are both ignored.
This is a serious, omission, FileMaker!
I have a WebDirect solution ready to roll, and now I have to go back and rebuild the whole damn thing in PHP and CWP just so I can pass a script parameter? Insane!
I realize this is a security issue, but security is not a huge deal with this solution. In fact, asking one of my users to "log in" to this solution will seem excessive and cause them to just not use it at all.
Please make this possible again, or give us a secure way to pass parameters!
Or, at the very least, update your webdirect guide / documentation to show that the feature is deprecated!
RB et. al. --
From: http://help.filemaker.com/app/answers/detail/a_id/13183 for the FMServer 13.0v2 update:
5.2. User interaction in FileMaker WebDirect solutions
The capability to specify URL parameters or to bookmark specific locations within FileMaker WebDirect solutions has been removed for security reasons. You now specify only a filename in the URL to open that file.
So the documentation is there, albeit only under the long list of changes in that update 13.0v2.
-- Drew Tenenholz
I thought of one other possible solution to this, wanted to run it by everyone here:
1) we email our customers with a customized link. The link takes them to a PHP page we've written and it passes a user-id as a parameter.
2) the PHP page accepts the user-id parameter. Then it fetches the client's WAN IP address using a PHP function, and we also grab the browser brand and version
3) the PHP page updates that user's record in our filemaker system, noting that this user has this particular browser and WAN IP.
4) the PHP page drives us to the webdirect solution automatically
5) the webdirect solution can't accept parameters, but it can independently determine the client's WAN ip and the browser brand and version using get(ApplicationVersion)
6) the web direct solution uses these automatically-determined values to query the database and figure out which unique user this (likely) is.
It's not foolproof, like if you had multiple customers with the same WAN IP and browser version, but it'd work most of the time.
What do you guys think?
You can use an "opener" database that performs a script. So put another database up on the webdirect and email that to whoever. When that database is opened it has an on-open script step that does the operations you want and goes to the right layout on your main database. Extra parameters like auto-login, record number, etc can be set in the opener
I tried something like you suggest above. But, I could not get the "open file..." script step to jump the user from the "opener" webdirect database to the main webdirect database.
Was I missing something?
Instead of using "open file", set the main database up as an external data source for the opener database. You can then call your start up script, which would reside in the main file, from the opener file.
I am so sorry for leading you up the garden path! You are right that it doesn't work. We tried that ourselves and it failed... Our solution in the end was that our source called a PHP script first that set some values in the database and that made the db open up to the correct section... Considerably more work than an opener database. Also I'm not in front of it now so I don't know exactly how we made it handle multiple users
Hi Jenfrew and others,
Yes, it does break the security in more than one way. But we need to be specific. Security is not something carved in stone and different situations can at times facilitate different ansvwers.
- It will send the credentials (user name and password) via email or any other method you choose.
- It will store the login/password included in the URL stored under history, bookmarks etc.
- It will send the password unencrypted across the internal or even worse across the internet included in the url.
- And there may be other potential pitfalls.
I am not advocating that FileMaker should ever let us include the passwords in URL's and therefore I do accept that the end user will have to enter his/her password. Always.
But answering some of the questions/issues:
- With some solutions we will when something specific occur send an email to the person including url, login and password and ask them to go and do something. This we will of course do in such an insecure manner with solutions where this is acceptable. View only or with non secret/person critical information etc.
- Yes, unless you have set up ssl for all communication with the apache/ISS server and WebDirect. I have not gone into depth with this.
- ? ... would like to hear, but #2 is conclusive, #3 can probably be handled, but will demand competent people setting up ISS/Apache. #1 may be absolutely OK.
I guess that no changes will be done. It would be nice to be able to include the username in the URL and then have the password pre-filled with this. But ... althogether I like the approach FileMaker has choosen.
I a can come op with quite a few use-cases where 1-2-3 as mentioned above would be absolutely acceptable. But it would require to many warnings from FileMaker to the unexperienced developer, and they may not read those ... remember how some of us usually treat warnings:-) comming up i dialoges.
And just 1 terrible mistake could end up bringing FileMaker to the front pages of websites and papers.
No go, although I need this feature for a specific solution and do have a justifiable annoid customer, and I understand why he has how dismissed WebDirect for just this reason. The solution defined that temporary accounts sould be automatically created by ServerScripts for the persons who must enter the solution in a safe way, send an email with the instruction with instruction to enter important information.
The login must be usable for 1 or a few times until the user deside to pres "Finish" or until 7 days has paased. Then a serverscript would delete the account.
It is a must defined by the customer that the login is via an url with the unique login and password. This must be very very easy for the customer.
We considered letting the customer go to a specific page in an unprotected WebDirect solution (one privilege set with guest enabled) and then the url sending the guest to a page specificly created to him in advance (like the one we would create on his/her first login) and then via settings in the privilege set making this page unavailable after it is finished. This is possible. But it is defined that the login must be secure with credentials. And we have therefore not suggested this shortcut.
We will build this simple solution entirely with PHP/FileMaker. And since we have people who are very good at that, it is OK for the customer and for us as well.
But there will never be more than 5-10 concurrent users of the very light solution .... so WebDirect would have been the dream solution.