Hacking iwp_auth.html

[xochi]

FM8 IWP has a major limitation: if you have both guest and non-guest accounts with IWP access, there is no easy way to allow the guests to enter the database via IWP without having them see the IWP login screen (iwp_auth.html). This problem does not appear to have been fixed in 8.0v4 or 8.5v1.

Other folks have encountered this same problem and come up with various solutions. However, all of these solutions have some limitations, such as requiring the use of sub-domains (e.g. database1.company.com, database2.company.com), only working for a single IWP hosted database, or requiring a paid solution.

For reference and to see where I borrowed some code:

http://fmwebschool.com/frm/index.php?topic=199.0

and

http://fmwebschool.com/frm/index.php?topic=218.0

I'm working on improving this system, with the following goals:

• Allow guests to use the database without seeing the login screen presented by iwp_auth.html
  
• Allow valid users to see the login screen
  
• Reduce or eliminate the need for custom URLs, shadow database files, etc.
  
• Allow access to multiple databases (having either guest-only access and guest+registered users) and multiple users.
  
• Allow a logged-in IWP user (either Guest or valid user) to re-login as another user
  
• Works on the same set of browsers & browser settings as normal FM8 IWP (e.g. javascript & cookies enabled).
  
• Provide the solution in the public domain for all to use free of charge.
  

Methods tried, without success:

If you can figure out a way to make any of these work, please let me know!

1. One should be able to pass a couple of extra URL parameters to the database open URL, and then check for these using JavaScript by modifying the iwp_auth.html page, e.g.

http://domainname.com/fmi/iwp/cgi?-db=testdb&-loadframes&x-force-login-db=database1

In practice, this doesn't seem to work.   The problem is that when IWP tries to open a database and authentication is needed, the IWP engine strips out any extra parameters (x-force-login-db) when it calls the iwp_auth.html page.   



2. Modifying iwp_auth.html to do an auto-login using a guest account (which works).  Then, in theory for valid users to login, we use the "Relogin" script step with blank username/password.  This should send them back to the iwp_auth.html login screen.    Unfortunately, this does't seem to work.   The problem is the same as the prior one -- when iwp_auth.html is loaded again, there's no way I could find to detect that a re-login is being requested, so the auto-login just happens again and bypasses the username/password fields, and you end up back in the database with the guest account.



My Compromise Method

I have found one solution that seems to work.  It's not perfect, but seems to be "good enough" for my needs.    The basic idea is to modify iwp_auth.html so that it always does an automatic guest login.     Then, from within IWP, we add a custom login screen that accepts a username and password, and then does a true ReLogin script step with the provided username/password.



Implementation Details:

1. Set up your database with two or more privilege sets that have the fmiwp extended privleges.   Set up two or more accounts that use these privelege sets.  One should be the Guest account, the other having whatever account(s) you wish).



2. Modify iwp_auth.html as follows, to force an automatic guest login:



Replace the login form (the one that starts with

With the following JavaScript code:

3. Set your database to have a script that runs when the database is opened (use the File Options -- "when opening his file Perform script: xxx" setting).  This script should check the privilege set and send them to the correct layout appropriate to their level of access.



Example (note -- you'll need to modify as appropriate to match your actual privilege set and layout names)

OpenScript:

If Get(PrivelegeSetName)= "IWP-Public"

  Go to layout IWP.Public.Welcome

else if Get(PrivelegeSetName)= "IWP-Valid-User"

  Go to layout IWP.ValidUser.Welcome

else

  // invalid username/password, go back and try again

  Go to layout IWP.Login

end if

4. Create two new global fields (gLoginUserName and gLoginPassword)



5. Create a new layout that has these two fields plus a "Login" button which triggers a script (say, "IWP.ReLogin")



6. the IWP.Relogin script should then do a relogin step using the username/password, and then call OpenScript to automatically go to the appropriate layout.  You should probably zero out the username & password fields for safety.



7. If you want the general public to have the option of trying to login using a valid username/password combo, add this link to your IWP.Public.Welcome screen, e.g. "Click here to relogin".   If you don't want them to see it, you'll need to hide it somewhere onscreen.



8. The URLs to open your databases can be the regular iwp format, e.g.

http://company.com/fmi/iwp/cgi?-db=database1&-startsession

How this works

• From your company's web page, the user clicks a link to open the database.
  
• The modified iwp_auth.html page forces an automatic login using the [Guest] account, and takes them to the public IWP layout.
  
• Users with a valid username/password click the "relogin" link (either prominently displayed, or hidden somewhere on the page), and are sent to your custom login layout.
  
• When they click the relogin button, if the username/password match a valid account, they are re-logged in and sent to the private layout.
  

Pros of using method

• Only requires a single edit to iwp_auth.html
  
• Works with multiple IWP databases hosted on a single server
  
• Free.
  
• Since most of the login navigation is within filemaker, and since you build your own login layout within filemaker, you can easily customize for your corporate look & feel.
  

Cons of using method

• Requires edits to iwp_auth.html, therefore probably not workable with shared hosting.
  
• Since the login password is typed within filemaker, it is a normal text field and thus visible onscreen. Not ideal if someone is looking over your shoulder.
  
• There is no way to send valid users directly to the login screen. You must first see the public layout, then click to get to the login layout.
  

[xochi]

NOTE TO MODERATOR: the code tags seem to be broken in this post, can you fix?

[Genx]

You wish we could fix

I just had a look at it, it seems the first post doesn't seem to like it, your second one works fine with the code tags though

It doesn't want to work in your first post for some reason (don't ask me). Try copying it into a new post 

[Steven H. Blackwell]

FM8 IWP has a major limitation: if you have both guest and non-guest accounts with IWP access, there is no easy way to allow the guests to enter the database via IWP without having them see the IWP login screen (iwp_auth.html). This problem does not appear to have been fixed in 8.0v4 or 8.5v1.

Implicit Guest Access (in FMP 7) was changed to Explicit Guest Access (FMP 8 and FMP 8.5) as part of the migration away from basic HTTP authentication and the blocking of stored session and site credentials. This is intended behavior, so I doubt anything will change here.

There are some techniques that can be used from the root level "home" page to address the need to allow either Guest Access without viewing the credentials challenge page or credentialed access using the credentials challenge page.

Steven

[xochi]

I think most of us are happy about forms-based access instead of http-auth. However, it seems to me that had FM made a couple of simple changes, this entire problem would be avoided.

FM should have provided a standard URL that would allow you to:

• open a particular database
  
• with a specified account name
  
• optionally, with a password
  
• optionally, with a parameter that could be accessed via some sort of Get function, like a script parameter...e.g. Get(IWPParameter)
  

This would allow IWP to really shine, as you could construct external links which did multiple actions:

e.g. /cgi/fmi/?-startsession&db=database1&user=johnsmith&password=xxx&parameter=AddABirthday20060417

I suppose this kind of thing is possible if one is using custom web publishing / XML /XSTL?

[tv_kid]

It was a while since you posted this, but I'm hoping you're still subscribed...

I'm having trouble getting what you describe to work. It did work once (!) but try as I might I cannot now get it to work. I've modified the 'iwp_auth.html' file as you suggest, but can't get an automatic login.

Any other tips I might try...?

Thanks

[xochi]

I'm here...the setup I did is still humming along working fine, so I'm pretty sure we can get you working too.

Can you give more details about what is/is not working, and the machine configurations?

[TysonB]

I am also having issues getting this to work, perhaps you can shed some light for me... Running FM 8.0v1, on MacOS X.4.8. I have IWP enabled (obviously). I have modified the iwp_auth.html file as you described, and when I try to hit the link for my database, which is this (of course with my server name changed to protect the innocent):

http://myserver.domain.ca:85/fmi/iwp/cgi?-db=mydatabase&-loadframes

all I get is a blank IWP window (ie, its got the IWP banner, but nothing else on it), with a url that looks like this:

http://myserver.domain.ca:85/fmi/iwp/res/iwp_auth.html?sid=01A9D697FE92D0EA118A8A1B (tried this in FireFox 1.5x)

I also had a question about the script step

"// invalid username/password, go back and try again"

What sort of script step is this?

I BELIEVE that I have this all set up right, with the possible exception of the script step above (since I couldn't figure out what it was....)

How am I supposed to have the "Instant Web Publishing access to file" set? For "All Users" is what I currently have.

Thanks in advance

Edited November 6, 2006 by Guest

[xochi]

I am also having issues getting this to work, perhaps you can shed some light for me... Running FM 8.0v1, on MacOS X.4.8. I have IWP enabled (obviously). I have modified the iwp_auth.html file as you described, and when I try to hit the link for my database, which is this (of course with my server name changed to protect the innocent)

http://myserver.domain.ca:85/fmi/iwp/cgi?-db=mydatabase&-loadframes

all I get is a blank IWP window (ie, its got the IWP banner, but nothing else on it), with a url that looks like this:

http://myserver.domain.ca:85/fmi/iwp/res/iwp_auth.html?sid=01A9D697FE92D0EA118A8A1B (tried this in FireFox 1.5x)

Some guesses:

1. Why are you using Port 85? Are you sure that your webserver is configured properly for this?

2. I suspect a syntax error in your html modifications -- what do your webserver logs say?

I also had a question about the script step

"// invalid username/password, go back and try again"

What sort of script step is this?

This is my shorthand for a comment script. "//" means "the following info is a comment only" in many programming languages.

I BELIEVE that I have this all set up right, with the possible exception of the script step above (since I couldn't figure out what it was....)

How am I supposed to have the "Instant Web Publishing access to file" set? For "All Users" is what I currently have.

Thanks in advance

I think your next step is to do some debugging -- you need to look at the webserver logs, filemaker logs, and open the page source(s) of the displayed pages that aren't working...

[tv_kid]

I have set up the facility for general users to auto log in to a database as a guest, via a url. This is working ok. However, I also need to be able to give a different url to other users who will log in with edit privileges. I'm trying to come up with a way of directing them to the login page, but as I have modified the iwp_auth.html file, it is automatically logging them in as a guest.

I thought that I could direct the users to a different iwp_home.html page, but can't see how to modify this to point to a different iwp_auth.html page.

Any ideas gratefully received.

[Son of a Beach]

Found this old thread, and have implemented it with some improvements.

Firstly, I also had the problem of the blank page with only the FMP banner at the top. This was solved by adding a closing tag to the end of the replacement text in iwp_auth.html.

Secondly, I've eliminated the need for registered users to enter via the public/guest page, and given then a completely separate URL to enter by.

I thought "surely it's not going to be this easy", but it was...

Instead of editing the iwp_auth.html file, create a copy of it called, eg, iwp_auth_guest.html, and make the changes from the OP to that new file instead.

Then in the URL, simply change the file name, and ta-da... the old URL still works for the login page, and the new URL works for automatic guest login.

This eliminates 2 1/2 of the 3 Cons in the original post (1/2 a con remaining because although you don't have to edit iwp_auth.html, the solution still has basically the same consequences, and therefore may not be suitable for some applications).

I guess it adds a new con though: may not be forward compatible - in future FileMaker may decide to make sure any HTML files that it doesn't know about do not work. Works fine for me on FMP 8 (not server).

(Not required now, but before coming up with this variation to the OP's method, I also made his password entry field use white text, so the password could not be visually snooped over the shoulder).

Wow... I've been searching for a way to use two URLs to log into the same database for Guest/non-guest logins for ages. This thread nearly solved the problem, and with a minor variation... it is now solved completely! Hooray!

This modification to the OP's original also makes the whole method so much easier to implement. There are now only two small steps required:

• Duplicate the iwp_auth.html file naming the new file something like "iwp_auth_guest.html".
  
  
• Change the content of the new iwp_auth_guest.html file replacing everything from "" (inclusive) with:
  

To use the database via IWP, normal registered account holders log in using a link to the usual login page, and guest use a link to the new login page (IE, in the URL substitute iwp_auth.html with iwp_auth_guest.html).

So simple!

Much thanks to the OP for getting me headed in the right direction.

Edited August 17, 2007 by Guest

[xochi]

Very nice, SOB :

Question -- how does your solution compare to this one:

http://edoshin.skeletonkey.com/2006/12/how_to_bypass_t.html

?

[Son of a Beach]

Hey, that's even better. Why couldn't I find that with all my searching? :

The main difference there is that my solution requires a custom file to be on the FMP server, whereas your solution provides for much better customisation, and doesn't require anything else to be installed on the FMP server.

You solution is much better (and is what I tried to come up with first, but couldn't find the right URL parameters).

Only change I would make to your solution is to use the "post" method instead of the "get" method to avoid the password appearing in the URL (although I can't see it in the URL at all even with the "get" method).

Very nice, and thanks for pointing me to it.

[Son of a Beach]

PS... Did anyone find a non-lasso way of solving the cookie problem? (Ie, if you don't explicitly log out of FMP/IWP, then further attempts will take you directly back to the same database with the same privileges).