Recent Microsoft Update breaks FM solutions!!!

[ibiubu]

I am not sure if other users have done this, but there are times that I want to direct users to a specific DB record using a redirect script in my web pages. I use a redirect script or inline action. This then includes all the information such as -db, -format, -find and etc. The user then goes to the page containing this redirect, the script then redirects them to what I want them to see. Easier than me trying to provide them with a long URL. Cleaner than having to put a link on the page and make them click.

Anyway, you can forget about doing this anymore. Microsoft just released a update Feb. 10th that makes changes to explorer on the PC. Anyone that applies this update will see a error page under the above scenario.

In other words, I have a couple of solutions that I host a blank page with my ISP provider. My clients go to that URL, that blank page loads, and they are re-directed to my internal FM server. Not anymore. With this new update installed, the user is not redirected, they just see a error page now.

Got to love Microsoft when they take it upon themselves to dictate what they think should and should not be internet standards. Now i wil have to re-do a lot of my pages.

LR

[cjaeger]

why not just use a frame with framesrc="yourwebserverathome/FMPro?blabla"

Should work, otherwise many domain resellers really get probs ...

No sript, no inline action.

[trevorg]

Are you certain that it's the redirect that is broken? Are you passing the username and password through the URL? (http://username:password@domain/FMPro?...)

Microsoft's recent update doesn't allow this anymore.

Here is the info regarding that issue.

Microsoft KB Article 834489

[ibiubu]

You are correct, I have confirmed this because I am passing a username and password through the URL such as (http://username:password@domain/FMPro?...) through my redirect script.

This is a HUGE problem. In fact, you can not even include username:password@ in a standard url link on a http page. I would imagine that other users use this method as well. Is there any other options to keep this working?

Larry

[ibiubu]

Got to just love Microsoft. Here is what they say users should do if they still want to include username and password information in URL's, and I quote:

"If users typically type HTTP or HTTPS URLs that include user information in the Address bar, or click links that include user information in HTTP or HTTPS URLs, you can work around this new functionality in Internet Explorer in two ways:

1. Do not include user information in HTTP or HTTPS URLs.

2. Instruct users not to include their user information when they type HTTP or HTTPS URLs."

What a great NON-SOLUTION they are providing us. I love how they say we can "work around" this issue by telling us to just not use this practice anymore.

Larry

[Mariano Peterson]

The work arounds you posted are directed at USERS. Naturally, there is nothing a USER can do.

However, the article does include tips for DEVELOPERS on how to redesign their process so as to cause the least disruption for USERS. Among their tips:

If you include HTTP or HTTPS URLs that contain user information in your scripting code, to manage state information, change your scripting code to use cookies instead of user information. For additional information about how to use cookies to manage state information, visit the following Internet Engineering Task Force (IETF) Web site:

http://www.ietf.org/rfc/rfc2965.txt

This is not really a problem if you are using standard middleware such as PHP, Lasso, ASP, etc. In those cases, you wouldn't submit HTTP authentication parameters in a URL, rather, you'd create your own web login system and track authenticated users with sessions and/or cookies. Usernames and passwords would be passed as URL query string parameters, such as ...script.php?username=john&password=doe. These are not affected by the changes in IE.

CDML has always been very limited. It does not work in a standard web scripting paradigm, and exposes FileMaker security vulnerabilities directly to the web. It is a much better approach to use FileMaker's CGI spec in conjuction with standard middleware. Once again, CDML scripters will need to find another work around to a standard problem.