views:

74

answers:

4

I'm seeing an intermittent problem on our web site. Some users are trying to submit forms via GET when my form method is POST. The errors always come from IE users. I have noticed a few UA strings have a reference to "yie8," which I am assuming is Yahoo's IE8 package. I think the Yahoo! toolbar might have something against me, but I can't replicate the problem on IE7 with the toolbar installed. The problem happens not only on this form, but various others, many of which are submitted via Ajax using the jQuery form plugin load() function with an object parameter passed. This example isn't one of those.

A simple fix would be to just take out all of my AcceptVerb() attributes, but that would be totally lame. Anyone ever come across something like this or have any ideas with dealing with it?


Here's an example exception log entry.

We've got a Web problem! Exception thrown:
http://my.web.site/User.mvc/ResetPassword
Method: GET

User: <not logged in>
UserAgent: IE 7 (Mozilla/4.0 (compatible; MSIE 7.0;Windows NT 5.1;.NET CLR 1.1.4322;.NET CLR 2.0.50727;.NET CLR 3.0.04506.30))

Exception: System.Web.HttpException
Message: A public action method 'ResetPassword' could not be found on controller 'MyApp.Controllers.UserController'.

Here's the HTML as it is rendered to the browser.

<form action="/User.mvc/ResetPassword" class="standard-form small-form" method="post"> 
    <fieldset> 
        <div class="row"> 
            <label for="usernameTextBox">User Name</label> 
            <input type="text" name="username" id="usernameTextBox" /> 
        </div> 
        <div class="row"> 
            <label for="emailTextBox">Email Address</label> 
            <input type="text" name="email" id="emailTextBox" /> 
        </div> 
        <div class="row"> 
            <label>&nbsp;</label> 
            <input type="submit" value="Reset Password" /> 
        </div> 
    </fieldset> 
</form> 

And here's the signature of my ResetPassword action.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult ResetPassword(string username, string email)

(and yes, the email address is required to match the one we have on file)

+1  A: 

I don't think you can do anything about this. Some browser plug-ins/toolbars have a feature which allows changing forms from GET -> POST and vice-versa.

If your users are doing this, there isn't really anything you can do.

Ben S
You may be right. What kind of toolbars that a "typical user" would have can do this? I would like to compile a simple "Help" section on my error page for dealing with this at the very least.
Stuart Branham
A: 

I'd say it isn't really your problem. You design your site to work as intended, you put your GET/POST restrictions on your methods (for security or other reasons).

If the user tries to get around your security with some advanced tools/plugins (such as GET/POST switches) it's not your concern. You might want, however, to add some custom error pages to handle those scenarios and warn the user accordingly.

Matteo Mosca
+1  A: 

When website visitors misbehave like this, you have to ask yourself, "What are the chances this is a legitimate misunderstanding?" In my opinion, using the wrong HTTP method is not something a browser does because it's old or buggy or whatever. It's an invalid request, so send 'em a 405 and be done with it.

(I have heard of some browsers and plugins trying to 'preload' pages that are reachable from the current page, but it's a lame 'feature'. My answer is still to treat it as an invalid request.)

grossvogel
The preloading thing is an interesting direction to look. Fortunately, our business is structured in a way that I can call clients and see if they actually are seeing these errors, or if they're silent errors.
Stuart Branham
+1  A: 

Possibly an answer raising more questions than actual answers, but in the spirit of trying to help...

On the GET calls, are "username" and "email" querystring parameters actually supplied? (your IIS log file may be recording query strings, so check there). If so, then the answer of Ben S may well apply.

If your web site is internet facing, then these calls may just be spiders not playing nicely.

If your site is internal, I'd suspect a user is playing with "refresh".

Have you tracked the client IP addresses which raise these errors?

Neil Moss
Our exception log also shows parameters passed. Often, there are none. On this particular error, it may actually have been a bot masquerading as IE7. Every action except for login/reset pass is protected, though, so a bot wouldn't be able to get in. We are seeing these on authenticated pages as well, but with the jQuery form plugin doing the actual form submission. That may be a separate question, though.
Stuart Branham
Ha, thanks for the heads up on tracking the IP. http://69.84.207.147/ (link is safe)
Stuart Branham
Ah - good ol' lightspeed. Is it responsible for all the errors?
Neil Moss
Just this one. As for the Ajax thing, I am actually using `jQuery.load()`, not `jQuery.form()`, and providing an object as a parameter, which is documented as using POST. This may be where my problem lies. I think I need to start getting my ducks in a row before posting these kinds of questions. ;-)
Stuart Branham