Verb gone missing?

[Hani Suleiman]

Using the latest cvs, the setHttpVerb function seems to have gone  
missing.

Whats the recommended way now of saying that all requests should be  
GET instead of POST? (yes, I know POST is better, but for very boring  
reasons involving NTLM, I need some pages to use GET for all dwr  
requests)



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Walker-3]

I posted some time ago for reasons why anyone would want to do that. Can you tell me more? POST works through NTLM doesn't it?

The reason I got rid if it (and pollMethod) is that DWR only treats them as a hint anyway. There are many cases where it decides that it's going to ignore your request. For example, script tags must use GET, anything with a input[type=file] must use a POST, etc, etc. By removing the option we admit that we can't do what you might have thought we could.

I'm happy to put something back in, but I would prefer to either demonstrate that you don't need it, or find a way to automatically detect your situation and work around it.
Thanks,

Joe.

On Feb 8, 2008 2:20 PM, Hani Suleiman <hani@...> wrote:

Using the latest cvs, the setHttpVerb function seems to have gone
missing.

Whats the recommended way now of saying that all requests should be
GET instead of POST? (yes, I know POST is better, but for very boring
reasons involving NTLM, I need some pages to use GET for all dwr
requests)



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hani Suleiman]

On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:

>
> I posted some time ago for reasons why anyone would want to do that.  
> Can you tell me more? POST works through NTLM doesn't it?
>
> The reason I got rid if it (and pollMethod) is that DWR only treats  
> them as a hint anyway. There are many cases where it decides that  
> it's going to ignore your request. For example, script tags must use  
> GET, anything with a input[type=file] must use a POST, etc, etc. By  
> removing the option we admit that we can't do what you might have  
> thought we could.
>
> I'm happy to put something back in, but I would prefer to either  
> demonstrate that you don't need it, or find a way to automatically  
> detect your situation and work around it.

The problem we have is that we allow for NTLM to be turned on/off on  
the fly, and users (well, this only applies to admin users, who can  
'override' NTLM) end up with their requests not working. It's an issue  
with NTLM that IE will in certain situations (such as when you switch  
it on/off) it will simply stop sending any POST body data.

However, since we're now using dwr in some fairly crucial admin pages,  
we need them to keep working even when the user does something stupid  
like that, and having the requests on those pages be GETs works around  
it.

Not very compelling I know, but it does save me many  
headaches...Though having said that, I did find a workaround, which to  
do this after dwr is loaded: dwr.engine.transport.xhr.httpMethod =  
'GET';

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hani Suleiman]

On Feb 8, 2008, at 9:49 AM, Hani Suleiman wrote:

> The problem we have is that we allow for NTLM to be turned on/off on  
> the fly, and users (well, this only applies to admin users, who can  
> 'override' NTLM) end up with their requests not working. It's an  
> issue with NTLM that IE will in certain situations (such as when you  
> switch it on/off) it will simply stop sending any POST body data.
>
FYI, here's the link that explains the issue: http://support.microsoft.com/?id=251404

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Joe Walker-3]

On Feb 8, 2008 2:49 PM, Hani Suleiman <hani@...> wrote:

On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:

>
> I posted some time ago for reasons why anyone would want to do that.
> Can you tell me more? POST works through NTLM doesn't it?
>
> The reason I got rid if it (and pollMethod) is that DWR only treats
> them as a hint anyway. There are many cases where it decides that
> it's going to ignore your request. For example, script tags must use
> GET, anything with a input[type=file] must use a POST, etc, etc. By
> removing the option we admit that we can't do what you might have
> thought we could.
>
> I'm happy to put something back in, but I would prefer to either
> demonstrate that you don't need it, or find a way to automatically
> detect your situation and work around it.

The problem we have is that we allow for NTLM to be turned on/off on
the fly, and users (well, this only applies to admin users, who can
'override' NTLM) end up with their requests not working. It's an issue
with NTLM that IE will in certain situations (such as when you switch
it on/off) it will simply stop sending any POST body data.

However, since we're now using dwr in some fairly crucial admin pages,
we need them to keep working even when the user does something stupid
like that, and having the requests on those pages be GETs works around
it.

Not very compelling I know, but it does save me many
headaches...Though having said that, I did find a workaround, which to
do this after dwr is loaded: dwr.engine.transport.xhr.httpMethod =
'GET';

So my take is that you're probably a bit of a corner case, and that we should document the workaround, but that this is a case where less is more.
Anyone: Feel free to argue.

Joe.

 

[benjwarner]

Hi Joe,
Just picking up on this issue, we seem to be experiencing a similar thing.

Using NTLM authentication (windows single sign-on), IE will require an NTLM negotiation for every POST request.  This involves 3 requests per POST to negotiate authentication.  It also involves the server going off to a domain controller to authenticate the user.

We are writing an application which polls the server every 5 seconds using DWR.  We have about 70 users, so that's about 70 DWR polls per 5 seconds.  This means that our domain controller is getting hit quite heavily from our application server.

IE does not require NTLM negotiation for GET requests, so having DWR set to httpMethod=GET would dramatically reduce the load we are putting on our network, and on our domain controller.

I'm hesitant about using the httpMethod parameter since it is marked for deprecation.  I just thought I'd add a bit more support for this issue, in case it helped change your mind.   

Thanks for your great work Joe,

Cheers,
Ben

Joe Walker-3 wrote:

On Feb 8, 2008 2:49 PM, Hani Suleiman <[e-mail]> wrote:

> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
>
> >
> > I posted some time ago for reasons why anyone would want to do that.
> > Can you tell me more? POST works through NTLM doesn't it?
> >
> > The reason I got rid if it (and pollMethod) is that DWR only treats
> > them as a hint anyway. There are many cases where it decides that
> > it's going to ignore your request. For example, script tags must use
> > GET, anything with a input[type=file] must use a POST, etc, etc. By
> > removing the option we admit that we can't do what you might have
> > thought we could.
> >
> > I'm happy to put something back in, but I would prefer to either
> > demonstrate that you don't need it, or find a way to automatically
> > detect your situation and work around it.
>
> The problem we have is that we allow for NTLM to be turned on/off on
> the fly, and users (well, this only applies to admin users, who can
> 'override' NTLM) end up with their requests not working. It's an issue
> with NTLM that IE will in certain situations (such as when you switch
> it on/off) it will simply stop sending any POST body data.
>
> However, since we're now using dwr in some fairly crucial admin pages,
> we need them to keep working even when the user does something stupid
> like that, and having the requests on those pages be GETs works around
> it.
>
> Not very compelling I know, but it does save me many
> headaches...Though having said that, I did find a workaround, which to
> do this after dwr is loaded: dwr.engine.transport.xhr.httpMethod =
> 'GET';


So my take is that you're probably a bit of a corner case, and that we
should document the workaround, but that this is a case where less is more.
Anyone: Feel free to argue.

Joe.

[mikewse]

Hi Ben,

It was a couple of years since I worked with NTLM, but I
don't remember anything about IE not doing NTLM for GET
requests - are you sure this is just not something you
have configured in your server? Do you have any pointers?

Are you using the JCIFS NTLM filter? In that case it
might be simpler to just make sure the poll URLs
  /dwr/call/plainpoll/
  /dwr/call/htmlpoll/
don't map to the filter.

Best regards
Mike Wilson

benjwarner wrote:

> Hi Joe,
> Just picking up on this issue, we seem to be experiencing a
> similar thing.
>
> Using NTLM authentication (windows single sign-on), IE will
> require an NTLM
> negotiation for every POST request.  This involves 3 requests
> per POST to
> negotiate authentication.  It also involves the server going
> off to a domain
> controller to authenticate the user.
>
> We are writing an application which polls the server every 5
> seconds using
> DWR.  We have about 70 users, so that's about 70 DWR polls
> per 5 seconds.
> This means that our domain controller is getting hit quite
> heavily from our
> application server.
>
> IE does not require NTLM negotiation for GET requests, so
> having DWR set to
> httpMethod=GET would dramatically reduce the load we are
> putting on our
> network, and on our domain controller.
>
> I'm hesitant about using the httpMethod parameter since it is
> marked for
> deprecation.  I just thought I'd add a bit more support for
> this issue, in
> case it helped change your mind.  :-)  
>
> Thanks for your great work Joe,
>
> Cheers,
> Ben
>
>
>
> Joe Walker-3 wrote:
> >
> > On Feb 8, 2008 2:49 PM, Hani Suleiman <hani@...> wrote:
> >
> >> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
> >>
> >> >
> >> > I posted some time ago for reasons why anyone would want
> to do that.
> >> > Can you tell me more? POST works through NTLM doesn't it?
> >> >
> >> > The reason I got rid if it (and pollMethod) is that DWR
> only treats
> >> > them as a hint anyway. There are many cases where it decides that
> >> > it's going to ignore your request. For example, script
> tags must use
> >> > GET, anything with a input[type=file] must use a POST,
> etc, etc. By
> >> > removing the option we admit that we can't do what you might have
> >> > thought we could.
> >> >
> >> > I'm happy to put something back in, but I would prefer to either
> >> > demonstrate that you don't need it, or find a way to
> automatically
> >> > detect your situation and work around it.
> >>
> >> The problem we have is that we allow for NTLM to be turned
> on/off on
> >> the fly, and users (well, this only applies to admin users, who can
> >> 'override' NTLM) end up with their requests not working.
> It's an issue
> >> with NTLM that IE will in certain situations (such as when
> you switch
> >> it on/off) it will simply stop sending any POST body data.
> >>
> >> However, since we're now using dwr in some fairly crucial
> admin pages,
> >> we need them to keep working even when the user does
> something stupid
> >> like that, and having the requests on those pages be GETs
> works around
> >> it.
> >>
> >> Not very compelling I know, but it does save me many
> >> headaches...Though having said that, I did find a
> workaround, which to
> >> do this after dwr is loaded: dwr.engine.transport.xhr.httpMethod =
> >> 'GET';
> >
> >
> > So my take is that you're probably a bit of a corner case,
> and that we
> > should document the workaround, but that this is a case
> where less is
> > more.
> > Anyone: Feel free to argue.
> >
> > Joe.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Verb-gone-missing--tp15356069p25640507.html
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[benjwarner ()]

Hi Mike,
Thanks for responding so quickly.

When any browser first connects to an NTLM filtered server, the server will always send back an "unauthorized" message which will force an NTLM negotiation.  After the session is established, IE will require NTLM negotiation for every subsequent POST.  (IE does not require negotiation for subsequent GETs.  Firefox does not require re-negotiation for subsequent GETs or POSTs).

I first realized this whilst doing some wireshark sniffing.  I then confirmed it on the web in a number of forums.

http://lists.samba.org/archive/jcifs/2008-February/007663.htm
http://www.websina.com/bugzero/kb/browser-ie.html

As far as I can tell there is no configuration in the server to stop this behavior, as it is IE which is the culprit.

Inspired by your suggestion I considered and actually created two polling DWR calls.   One to use normally which bypasses the NTLM filter, and one to use when any sort of error is detected, which does hit the NTLM filter.  This will ensure that if the server bounces, the poll will still be able to re-authenticate.

However this did not work.  As per my comment at the start of this reply it was bound to fail.  Even if I have a polling DWR call which bypasses the NTLM filter, IE is still going to require NTLM re-negotiation on a post, irrespective of how I have my filters configured.  So it will not send post parameters until a successful negotiation has completed.

So back to square one!  Apart from re-writing the JCIFs NTLM filter, I can't think of anyway to circumvent NTLM re-authentication, unless I have my ajax using GETs.

Cheers,
Ben

mikewse wrote:

Hi Ben,

It was a couple of years since I worked with NTLM, but I
don't remember anything about IE not doing NTLM for GET
requests - are you sure this is just not something you
have configured in your server? Do you have any pointers?

Are you using the JCIFS NTLM filter? In that case it
might be simpler to just make sure the poll URLs
  /dwr/call/plainpoll/
  /dwr/call/htmlpoll/
don't map to the filter.

Best regards
Mike Wilson

benjwarner wrote:
> Hi Joe,
> Just picking up on this issue, we seem to be experiencing a
> similar thing.
>
> Using NTLM authentication (windows single sign-on), IE will
> require an NTLM
> negotiation for every POST request.  This involves 3 requests
> per POST to
> negotiate authentication.  It also involves the server going
> off to a domain
> controller to authenticate the user.
>
> We are writing an application which polls the server every 5
> seconds using
> DWR.  We have about 70 users, so that's about 70 DWR polls
> per 5 seconds.
> This means that our domain controller is getting hit quite
> heavily from our
> application server.
>
> IE does not require NTLM negotiation for GET requests, so
> having DWR set to
> httpMethod=GET would dramatically reduce the load we are
> putting on our
> network, and on our domain controller.
>
> I'm hesitant about using the httpMethod parameter since it is
> marked for
> deprecation.  I just thought I'd add a bit more support for
> this issue, in
> case it helped change your mind.  :-)  
>
> Thanks for your great work Joe,
>
> Cheers,
> Ben
>
>
>
> Joe Walker-3 wrote:
> >
> > On Feb 8, 2008 2:49 PM, Hani Suleiman <[e-mail]> wrote:
> >
> >> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
> >>
> >> >
> >> > I posted some time ago for reasons why anyone would want
> to do that.
> >> > Can you tell me more? POST works through NTLM doesn't it?
> >> >
> >> > The reason I got rid if it (and pollMethod) is that DWR
> only treats
> >> > them as a hint anyway. There are many cases where it decides that
> >> > it's going to ignore your request. For example, script
> tags must use
> >> > GET, anything with a input[type=file] must use a POST,
> etc, etc. By
> >> > removing the option we admit that we can't do what you might have
> >> > thought we could.
> >> >
> >> > I'm happy to put something back in, but I would prefer to either
> >> > demonstrate that you don't need it, or find a way to
> automatically
> >> > detect your situation and work around it.
> >>
> >> The problem we have is that we allow for NTLM to be turned
> on/off on
> >> the fly, and users (well, this only applies to admin users, who can
> >> 'override' NTLM) end up with their requests not working.
> It's an issue
> >> with NTLM that IE will in certain situations (such as when
> you switch
> >> it on/off) it will simply stop sending any POST body data.
> >>
> >> However, since we're now using dwr in some fairly crucial
> admin pages,
> >> we need them to keep working even when the user does
> something stupid
> >> like that, and having the requests on those pages be GETs
> works around
> >> it.
> >>
> >> Not very compelling I know, but it does save me many
> >> headaches...Though having said that, I did find a
> workaround, which to
> >> do this after dwr is loaded: dwr.engine.transport.xhr.httpMethod =
> >> 'GET';
> >
> >
> > So my take is that you're probably a bit of a corner case,
> and that we
> > should document the workaround, but that this is a case
> where less is
> > more.
> > Anyone: Feel free to argue.
> >
> > Joe.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Verb-gone-missing--tp15356069p25640507.html
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [e-mail]
For additional commands, e-mail: [e-mail]

[mikewse]

Hi Ben,

benjwarner wrote:

> When any browser first connects to an NTLM filtered server,
> the server will
> always send back an "unauthorized" message which will force an NTLM
> negotiation.  After the session is established, IE will require NTLM
> negotiation for every subsequent POST.  (IE does not require
> negotiation for
> subsequent GETs.  Firefox does not require re-negotiation for
> subsequent GETs or POSTs).
>
> I first realized this whilst doing some wireshark sniffing.

Interesting. Back in the day I also did some Wireshark sniffs, but
my (somewhat vague) recollection is that we also had the "three
request auth cycle" for GET requests. Could be wrong though.
(We were on IE6 but it seems your links say that behaviour has been
the same since IE5.)

> I then confirmed it on the web in a number of forums.
>
> http://lists.samba.org/archive/jcifs/2008-February/007663.htm
> http://lists.samba.org/archive/jcifs/2008-February/007663.htm 

(You missed the ending "l" :-)
http://lists.samba.org/archive/jcifs/2008-February/007663.html

> http://www.websina.com/bugzero/kb/browser-ie.html
> http://www.websina.com/bugzero/kb/browser-ie.html 
>
> As far as I can tell there is no configuration in the server
> to stop this behavior, as it is IE which is the culprit.

What I was thinking about was that maybe your own code was
bypassing the NtlmHttpFilter for GET requests. But from reading
your links it seems that this would have no effect, as once one
NTLM handshake has been performed, IE will assume that all
requests to that "server folder" will use NTLM.

> Inspired by your suggestion I created two polling DWR calls.  
> One to use normally which bypasses the NTLM filter, and one to
> use when any sort of error is detected, which does hit the NTLM
> filter.  This will ensure that if the server bounces, the poll
> will still be able to re-authenticate.

I now realize that you are doing "manual" polls - ignore my
previous text about /dwr/call/plainpoll etc as that was about
Reverse Ajax polls.

Your solution sounds analogous to what I proposed, somehow making
the NTLM challenge chain (as triggered by NtlmHttpFilter)
conditional.
My thinking was that the first NTLM handshake would set up the
logged in user on your HttpSession, and NTLM auth would then not
be required for every request to this session.

> This is not ideal for us, as we now have two separate DWR calls,
> and a filter condition to include one of them in the NTLM
> filtering.  I would still support keeping the httpMethod
> parameter, however the mentioned solution does work, so the need
> for the httpMethod is less urgent.

I think it would be interesting to know for what IE versions
(6/7/8) the workaround is needed. NTLM is already a fairly
uncommon setup (common in enterprise scenarios though!) so if the
problem only occurs on a dying browser like IE6, then we might
not take so much action to resolve the problem as long as there
is a workaround. It would also be interesting to hear where you
think the problem really should be resolved; in DWR or in the
NtlmHttpFilter? (fixing it in IE would probably be the right
answer but I'm not including that as an option ;-)

Best regards
Mike

> mikewse wrote:
> >
> > Hi Ben,
> >
> > It was a couple of years since I worked with NTLM, but I
> > don't remember anything about IE not doing NTLM for GET
> > requests - are you sure this is just not something you
> > have configured in your server? Do you have any pointers?
> >
> > Are you using the JCIFS NTLM filter? In that case it
> > might be simpler to just make sure the poll URLs
> >   /dwr/call/plainpoll/
> >   /dwr/call/htmlpoll/
> > don't map to the filter.
> >
> > Best regards
> > Mike Wilson
> >
> > benjwarner wrote:
> >> Hi Joe,
> >> Just picking up on this issue, we seem to be experiencing a
> >> similar thing.
> >>
> >> Using NTLM authentication (windows single sign-on), IE will
> >> require an NTLM
> >> negotiation for every POST request.  This involves 3 requests
> >> per POST to
> >> negotiate authentication.  It also involves the server going
> >> off to a domain
> >> controller to authenticate the user.
> >>
> >> We are writing an application which polls the server every 5
> >> seconds using
> >> DWR.  We have about 70 users, so that's about 70 DWR polls
> >> per 5 seconds.
> >> This means that our domain controller is getting hit quite
> >> heavily from our
> >> application server.
> >>
> >> IE does not require NTLM negotiation for GET requests, so
> >> having DWR set to
> >> httpMethod=GET would dramatically reduce the load we are
> >> putting on our
> >> network, and on our domain controller.
> >>
> >> I'm hesitant about using the httpMethod parameter since it is
> >> marked for
> >> deprecation.  I just thought I'd add a bit more support for
> >> this issue, in
> >> case it helped change your mind.  :-)  
> >>
> >> Thanks for your great work Joe,
> >>
> >> Cheers,
> >> Ben
> >>
> >>
> >>
> >> Joe Walker-3 wrote:
> >> >
> >> > On Feb 8, 2008 2:49 PM, Hani Suleiman <hani@...> wrote:
> >> >
> >> >> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
> >> >>
> >> >> >
> >> >> > I posted some time ago for reasons why anyone would want
> >> to do that.
> >> >> > Can you tell me more? POST works through NTLM doesn't it?
> >> >> >
> >> >> > The reason I got rid if it (and pollMethod) is that DWR
> >> only treats
> >> >> > them as a hint anyway. There are many cases where it
> decides that
> >> >> > it's going to ignore your request. For example, script
> >> tags must use
> >> >> > GET, anything with a input[type=file] must use a POST,
> >> etc, etc. By
> >> >> > removing the option we admit that we can't do what
> you might have
> >> >> > thought we could.
> >> >> >
> >> >> > I'm happy to put something back in, but I would
> prefer to either
> >> >> > demonstrate that you don't need it, or find a way to
> >> automatically
> >> >> > detect your situation and work around it.
> >> >>
> >> >> The problem we have is that we allow for NTLM to be turned
> >> on/off on
> >> >> the fly, and users (well, this only applies to admin
> users, who can
> >> >> 'override' NTLM) end up with their requests not working.
> >> It's an issue
> >> >> with NTLM that IE will in certain situations (such as when
> >> you switch
> >> >> it on/off) it will simply stop sending any POST body data.
> >> >>
> >> >> However, since we're now using dwr in some fairly crucial
> >> admin pages,
> >> >> we need them to keep working even when the user does
> >> something stupid
> >> >> like that, and having the requests on those pages be GETs
> >> works around
> >> >> it.
> >> >>
> >> >> Not very compelling I know, but it does save me many
> >> >> headaches...Though having said that, I did find a
> >> workaround, which to
> >> >> do this after dwr is loaded:
> dwr.engine.transport.xhr.httpMethod =
> >> >> 'GET';
> >> >
> >> >
> >> > So my take is that you're probably a bit of a corner case,
> >> and that we
> >> > should document the workaround, but that this is a case
> >> where less is
> >> > more.
> >> > Anyone: Feel free to argue.
> >> >
> >> > Joe.
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Verb-gone-missing--tp15356069p25640507.html
> >> Sent from the DWR - Dev mailing list archive at Nabble.com.
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >> For additional commands, e-mail: dev-help@...
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Verb-gone-missing--tp15356069p25654579.html
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[benjwarner]

Hiya Mike,
> What I was thinking about was that maybe your own code was
> bypassing the NtlmHttpFilter for GET requests. But from reading
> your links it seems that this would have no effect, as once one
> NTLM handshake has been performed, IE will assume that all
> requests to that "server folder" will use NTLM.

Yes that is correct, the problem is that once IE has NTLM authenticated, IE will require that NTLM authentication occur on a per post basis.  IE will not send any post parameters until it has completed an NTLM negotiation.  So even if setup my app so that subsequent polls bypass the NTLM filter, my app would not receive any post parameters.

Saying this, I did find a hack which can be done at the filter level.  I've uploaded a OncePerSessionNtlmHttpFilter.  This filter stores the user credentials in the HttpSession.  On subsequent posts, the filter will return an "Unauthorized" message to IE.  IE will then assume the connection does not need to be authorized, and it will send it's post parameters in the next request.  
I've tested the filter and it seems to work ok.  It's not the best solution as it is clearly a hack but seems to work for now.  Not sure how much we can rely on this loophole being present in future releases of IE....

OncePerSessionNtlmHttpFilter.java

And just to correct something I said previously, the JCIFs NtlmHttpFilter does actually cache users connections for 5 minutes.  It overrides the parameter jcifs.smb.client.soTimeout documented here: http://jcifs.samba.org/src/docs/ntlmhttpauth.html.  So although this polling will require many authentications in terms of back and forth to the web server, there should not be much of an increase in traffic to the domain controller.

> I think it would be interesting to know for what IE versions
> (6/7/8) the workaround is needed. NTLM is already a fairly
> uncommon setup (common in enterprise scenarios though!) so if the
> problem only occurs on a dying browser like IE6, then we might
> not take so much action to resolve the problem as long as there
> is a workaround.

I've just retested and can confirm that both IE6 and IE7 require NTLM authentication on subsequent posts.  Have not tested IE8 as am a bit scared to install it!

>It would also be interesting to hear where you
>think the problem really should be resolved; in DWR or in the
>NtlmHttpFilter? (fixing it in IE would probably be the right
>answer but I'm not including that as an option ;-)

mmmmm, good question!  As far as I can tell it is not possible to fix it in NtlmHttpFilter without doing a hack as in the attached file.  And the number of "polling" apps is only going to increase in corporations, so I'm guessing that this problem will become more frequent.

Having said that, as there are some workarounds as listed above, it is definitely not a show-stopper if it were not possible in the future to set the httpMethod in DWR to GET, so I think it's more of a "nice-to-have" in DWR.  If allowing GETs in DWR did not negatively effect other things, I'd probably leave the httpMethod parameter in.  If it did cause problems, I'd have to weigh up the pros and cons.

Thanks for your time Mike.

Cheers,
Ben

mikewse wrote:

>Hi Ben,
>
>benjwarner wrote:
>> When any browser first connects to an NTLM filtered server,
>> the server will
>> always send back an "unauthorized" message which will force an NTLM
>> negotiation.  After the session is established, IE will require NTLM
>> negotiation for every subsequent POST.  (IE does not require
>> negotiation for
>> subsequent GETs.  Firefox does not require re-negotiation for
>> subsequent GETs or POSTs).
>>
>> I first realized this whilst doing some wireshark sniffing.
>
>Interesting. Back in the day I also did some Wireshark sniffs, but
>my (somewhat vague) recollection is that we also had the "three
>request auth cycle" for GET requests. Could be wrong though.
>(We were on IE6 but it seems your links say that behaviour has been
>the same since IE5.)

You are probably correct in saying this.

>
>> I then confirmed it on the web in a number of forums.
>>
>> http://lists.samba.org/archive/jcifs/2008-February/007663.htm
>> http://lists.samba.org/archive/jcifs/2008-February/007663.htm 
>
>(You missed the ending "l" :-)
>http://lists.samba.org/archive/jcifs/2008-February/007663.html
>
>> http://www.websina.com/bugzero/kb/browser-ie.html
>> http://www.websina.com/bugzero/kb/browser-ie.html 
>>
>> As far as I can tell there is no configuration in the server
>> to stop this behavior, as it is IE which is the culprit.
>
>What I was thinking about was that maybe your own code was
>bypassing the NtlmHttpFilter for GET requests. But from reading
>your links it seems that this would have no effect, as once one
>NTLM handshake has been performed, IE will assume that all
>requests to that "server folder" will use NTLM.




>> Inspired by your suggestion I created two polling DWR calls.  
>> One to use normally which bypasses the NTLM filter, and one to
>> use when any sort of error is detected, which does hit the NTLM
>> filter.  This will ensure that if the server bounces, the poll
>> will still be able to re-authenticate.
>
>I now realize that you are doing "manual" polls - ignore my
>previous text about /dwr/call/plainpoll etc as that was about
>Reverse Ajax polls.
>
>Your solution sounds analogous to what I proposed, somehow making
>the NTLM challenge chain (as triggered by NtlmHttpFilter)
>conditional.
>My thinking was that the first NTLM handshake would set up the
>logged in user on your HttpSession, and NTLM auth would then not
>be required for every request to this session.
>
>> This is not ideal for us, as we now have two separate DWR calls,
>> and a filter condition to include one of them in the NTLM
>> filtering.  I would still support keeping the httpMethod
>> parameter, however the mentioned solution does work, so the need
>> for the httpMethod is less urgent.
>
>I think it would be interesting to know for what IE versions
>(6/7/8) the workaround is needed. NTLM is already a fairly
>uncommon setup (common in enterprise scenarios though!) so if the
>problem only occurs on a dying browser like IE6, then we might
>not take so much action to resolve the problem as long as there
>is a workaround. It would also be interesting to hear where you
>think the problem really should be resolved; in DWR or in the
>NtlmHttpFilter? (fixing it in IE would probably be the right
>answer but I'm not including that as an option ;-)
>
>Best regards
>Mike
>
>> mikewse wrote:
>> >
>> > Hi Ben,
>> >
>> > It was a couple of years since I worked with NTLM, but I
>> > don't remember anything about IE not doing NTLM for GET
>> > requests - are you sure this is just not something you
>> > have configured in your server? Do you have any pointers?
>> >
>> > Are you using the JCIFS NTLM filter? In that case it
>> > might be simpler to just make sure the poll URLs
>> >   /dwr/call/plainpoll/
>> >   /dwr/call/htmlpoll/
>> > don't map to the filter.
>> >
>> > Best regards
>> > Mike Wilson
>> >
>> > benjwarner wrote:
>> >> Hi Joe,
>> >> Just picking up on this issue, we seem to be experiencing a
>> >> similar thing.
>> >>
>> >> Using NTLM authentication (windows single sign-on), IE will
>> >> require an NTLM
>> >> negotiation for every POST request.  This involves 3 requests
>> >> per POST to
>> >> negotiate authentication.  It also involves the server going
>> >> off to a domain
>> >> controller to authenticate the user.
>> >>
>> >> We are writing an application which polls the server every 5
>> >> seconds using
>> >> DWR.  We have about 70 users, so that's about 70 DWR polls
>> >> per 5 seconds.
>> >> This means that our domain controller is getting hit quite
>> >> heavily from our
>> >> application server.
>> >>
>> >> IE does not require NTLM negotiation for GET requests, so
>> >> having DWR set to
>> >> httpMethod=GET would dramatically reduce the load we are
>> >> putting on our
>> >> network, and on our domain controller.
>> >>
>> >> I'm hesitant about using the httpMethod parameter since it is
>> >> marked for
>> >> deprecation.  I just thought I'd add a bit more support for
>> >> this issue, in
>> >> case it helped change your mind.  :-)  
>> >>
>> >> Thanks for your great work Joe,
>> >>
>> >> Cheers,
>> >> Ben
>> >>
>> >>
>> >>
>> >> Joe Walker-3 wrote:
>> >> >
>> >> > On Feb 8, 2008 2:49 PM, Hani Suleiman <[e-mail]> wrote:
>> >> >
>> >> >> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
>> >> >>
>> >> >> >
>> >> >> > I posted some time ago for reasons why anyone would want
>> >> to do that.
>> >> >> > Can you tell me more? POST works through NTLM doesn't it?
>> >> >> >
>> >> >> > The reason I got rid if it (and pollMethod) is that DWR
>> >> only treats
>> >> >> > them as a hint anyway. There are many cases where it
>> decides that
>> >> >> > it's going to ignore your request. For example, script
>> >> tags must use
>> >> >> > GET, anything with a input[type=file] must use a POST,
>> >> etc, etc. By
>> >> >> > removing the option we admit that we can't do what
>> you might have
>> >> >> > thought we could.
>> >> >> >
>> >> >> > I'm happy to put something back in, but I would
>> prefer to either
>> >> >> > demonstrate that you don't need it, or find a way to
>> >> automatically
>> >> >> > detect your situation and work around it.
>> >> >>
>> >> >> The problem we have is that we allow for NTLM to be turned
>> >> on/off on
>> >> >> the fly, and users (well, this only applies to admin
>> users, who can
>> >> >> 'override' NTLM) end up with their requests not working.
>> >> It's an issue
>> >> >> with NTLM that IE will in certain situations (such as when
>> >> you switch
>> >> >> it on/off) it will simply stop sending any POST body data.
>> >> >>
>> >> >> However, since we're now using dwr in some fairly crucial
>> >> admin pages,
>> >> >> we need them to keep working even when the user does
>> >> something stupid
>> >> >> like that, and having the requests on those pages be GETs
>> >> works around
>> >> >> it.
>> >> >>
>> >> >> Not very compelling I know, but it does save me many
>> >> >> headaches...Though having said that, I did find a
>> >> workaround, which to
>> >> >> do this after dwr is loaded:
>> dwr.engine.transport.xhr.httpMethod =
>> >> >> 'GET';
>> >> >
>> >> >
>> >> > So my take is that you're probably a bit of a corner case,
>> >> and that we
>> >> > should document the workaround, but that this is a case
>> >> where less is
>> >> > more.
>> >> > Anyone: Feel free to argue.
>> >> >
>> >> > Joe.
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Verb-gone-missing--tp15356069p25640507.html
>> >> Sent from the DWR - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [e-mail]
>> >> For additional commands, e-mail: [e-mail]
>> >>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [e-mail]
>> > For additional commands, e-mail: [e-mail]
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Verb-gone-missing--tp15356069p25654579.html
>> Sent from the DWR - Dev mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [e-mail]
>For additional commands, e-mail: [e-mail]
>

[mikewse]

Ok, good :-)
I'm noting down your statements in my personal to-do list for
future things to consider after 3.0.

If you get a chance to test on IE8, it'd be really great to
hear about. I can recommend installing any of the free
virtualization solutions such as VmWare Player|Server or
MS Virtual PC.

If you go for VPC, you can even get free pre-installed VMs
with your desired IE versions from Microsoft; check the list
at the bottom of:
http://www.microsoft.com/Downloads/details.aspx?FamilyID=21eabb90-958f-4b64-
b5f1-73d0a413c8ef&displaylang=en

Best regards
Mike

benjwarner wrote:

> Hiya Mike,
> > What I was thinking about was that maybe your own code was
> > bypassing the NtlmHttpFilter for GET requests. But from reading
> > your links it seems that this would have no effect, as once one
> > NTLM handshake has been performed, IE will assume that all
> > requests to that "server folder" will use NTLM.
>
> Yes that is correct, the problem is that once IE has NTLM
> authenticated, IE
> will require that NTLM authentication occur on a per post
> basis.  IE will
> not send any post parameters until it has completed an NTLM
> negotiation.  So
> even if setup my app so that subsequent polls bypass the NTLM
> filter, my app
> would not receive any post parameters.
>
> Saying this, I did find a hack which can be done at the
> filter level.  I've
> uploaded a OncePerSessionNtlmHttpFilter.  This filter stores the user
> credentials in the HttpSession.  On subsequent posts, the
> filter will return
> an "Unauthorized" message to IE.  IE will then assume the
> connection does
> not need to be authorized, and it will send it's post
> parameters in the next
> request.  
> I've tested the filter and it seems to work ok.  It's not the
> best solution
> as it is clearly a hack but seems to work for now.  Not sure
> how much we can
> rely on this loophole being present in future releases of IE....
>
> http://www.nabble.com/file/p25708278/OncePerSessionNtlmHttpFilter.java
> OncePerSessionNtlmHttpFilter.java
>
> And just to correct something I said previously, the JCIFs
> NtlmHttpFilter
> does actually cache users connections for 5 minutes.  It overrides the
> parameter jcifs.smb.client.soTimeout documented here:
> http://jcifs.samba.org/src/docs/ntlmhttpauth.html
> http://jcifs.samba.org/src/docs/ntlmhttpauth.html .  So although this
> polling will require many authentications in terms of back
> and forth to the
> web server, there should not be much of an increase in
> traffic to the domain
> controller.
>
> > I think it would be interesting to know for what IE versions
> > (6/7/8) the workaround is needed. NTLM is already a fairly
> > uncommon setup (common in enterprise scenarios though!) so if the
> > problem only occurs on a dying browser like IE6, then we might
> > not take so much action to resolve the problem as long as there
> > is a workaround.
>
> I've just retested and can confirm that both IE6 and IE7 require NTLM
> authentication on subsequent posts.  Have not tested IE8 as
> am a bit scared
> to install it!
>
> >It would also be interesting to hear where you
> >think the problem really should be resolved; in DWR or in the
> >NtlmHttpFilter? (fixing it in IE would probably be the right
> >answer but I'm not including that as an option ;-)
>
> mmmmm, good question!  As far as I can tell it is not
> possible to fix it in
> NtlmHttpFilter without doing a hack as in the attached file.  
> And the number
> of "polling" apps is only going to increase in corporations,
> so I'm guessing
> that this problem will become more frequent.
>
> Having said that, as there are some workarounds as listed above, it is
> definitely not a show-stopper if it were not possible in the
> future to set
> the httpMethod in DWR to GET, so I think it's more of a
> "nice-to-have" in
> DWR.  If allowing GETs in DWR did not negatively effect other
> things, I'd
> probably leave the httpMethod parameter in.  If it did cause
> problems, I'd
> have to weigh up the pros and cons.
>
> Thanks for your time Mike.
>
> Cheers,
> Ben
>
>
>
>
> mikewse wrote:
> >
> >>Hi Ben,
> >>
> >>benjwarner wrote:
> >>> When any browser first connects to an NTLM filtered server,
> >>> the server will
> >>> always send back an "unauthorized" message which will
> force an NTLM
> >>> negotiation.  After the session is established, IE will
> require NTLM
> >>> negotiation for every subsequent POST.  (IE does not require
> >>> negotiation for
> >>> subsequent GETs.  Firefox does not require re-negotiation for
> >>> subsequent GETs or POSTs).
> >>>
> >>> I first realized this whilst doing some wireshark sniffing.
> >>
> >>Interesting. Back in the day I also did some Wireshark sniffs, but
> >>my (somewhat vague) recollection is that we also had the "three
> >>request auth cycle" for GET requests. Could be wrong though.
> >>(We were on IE6 but it seems your links say that behaviour has been
> >>the same since IE5.)
> >
> > You are probably correct in saying this.
> >
> >>
> >>> I then confirmed it on the web in a number of forums.
> >>>
> >>> http://lists.samba.org/archive/jcifs/2008-February/007663.htm
> >>> http://lists.samba.org/archive/jcifs/2008-February/007663.htm 
> >>
> >>(You missed the ending "l" :-)
> >>http://lists.samba.org/archive/jcifs/2008-February/007663.html
> >>
> >>> http://www.websina.com/bugzero/kb/browser-ie.html
> >>> http://www.websina.com/bugzero/kb/browser-ie.html 
> >>>
> >>> As far as I can tell there is no configuration in the server
> >>> to stop this behavior, as it is IE which is the culprit.
> >>
> >>What I was thinking about was that maybe your own code was
> >>bypassing the NtlmHttpFilter for GET requests. But from reading
> >>your links it seems that this would have no effect, as once one
> >>NTLM handshake has been performed, IE will assume that all
> >>requests to that "server folder" will use NTLM.
> >
> >
> >
> >
> >>> Inspired by your suggestion I created two polling DWR calls.  
> >>> One to use normally which bypasses the NTLM filter, and one to
> >>> use when any sort of error is detected, which does hit the NTLM
> >>> filter.  This will ensure that if the server bounces, the poll
> >>> will still be able to re-authenticate.
> >>
> >>I now realize that you are doing "manual" polls - ignore my
> >>previous text about /dwr/call/plainpoll etc as that was about
> >>Reverse Ajax polls.
> >>
> >>Your solution sounds analogous to what I proposed, somehow making
> >>the NTLM challenge chain (as triggered by NtlmHttpFilter)
> >>conditional.
> >>My thinking was that the first NTLM handshake would set up the
> >>logged in user on your HttpSession, and NTLM auth would then not
> >>be required for every request to this session.
> >>
> >>> This is not ideal for us, as we now have two separate DWR calls,
> >>> and a filter condition to include one of them in the NTLM
> >>> filtering.  I would still support keeping the httpMethod
> >>> parameter, however the mentioned solution does work, so the need
> >>> for the httpMethod is less urgent.
> >>
> >>I think it would be interesting to know for what IE versions
> >>(6/7/8) the workaround is needed. NTLM is already a fairly
> >>uncommon setup (common in enterprise scenarios though!) so if the
> >>problem only occurs on a dying browser like IE6, then we might
> >>not take so much action to resolve the problem as long as there
> >>is a workaround. It would also be interesting to hear where you
> >>think the problem really should be resolved; in DWR or in the
> >>NtlmHttpFilter? (fixing it in IE would probably be the right
> >>answer but I'm not including that as an option ;-)
> >>
> >>Best regards
> >>Mike
> >>
> >>> mikewse wrote:
> >>> >
> >>> > Hi Ben,
> >>> >
> >>> > It was a couple of years since I worked with NTLM, but I
> >>> > don't remember anything about IE not doing NTLM for GET
> >>> > requests - are you sure this is just not something you
> >>> > have configured in your server? Do you have any pointers?
> >>> >
> >>> > Are you using the JCIFS NTLM filter? In that case it
> >>> > might be simpler to just make sure the poll URLs
> >>> >   /dwr/call/plainpoll/
> >>> >   /dwr/call/htmlpoll/
> >>> > don't map to the filter.
> >>> >
> >>> > Best regards
> >>> > Mike Wilson
> >>> >
> >>> > benjwarner wrote:
> >>> >> Hi Joe,
> >>> >> Just picking up on this issue, we seem to be experiencing a
> >>> >> similar thing.
> >>> >>
> >>> >> Using NTLM authentication (windows single sign-on), IE will
> >>> >> require an NTLM
> >>> >> negotiation for every POST request.  This involves 3 requests
> >>> >> per POST to
> >>> >> negotiate authentication.  It also involves the server going
> >>> >> off to a domain
> >>> >> controller to authenticate the user.
> >>> >>
> >>> >> We are writing an application which polls the server every 5
> >>> >> seconds using
> >>> >> DWR.  We have about 70 users, so that's about 70 DWR polls
> >>> >> per 5 seconds.
> >>> >> This means that our domain controller is getting hit quite
> >>> >> heavily from our
> >>> >> application server.
> >>> >>
> >>> >> IE does not require NTLM negotiation for GET requests, so
> >>> >> having DWR set to
> >>> >> httpMethod=GET would dramatically reduce the load we are
> >>> >> putting on our
> >>> >> network, and on our domain controller.
> >>> >>
> >>> >> I'm hesitant about using the httpMethod parameter since it is
> >>> >> marked for
> >>> >> deprecation.  I just thought I'd add a bit more support for
> >>> >> this issue, in
> >>> >> case it helped change your mind.  :-)  
> >>> >>
> >>> >> Thanks for your great work Joe,
> >>> >>
> >>> >> Cheers,
> >>> >> Ben
> >>> >>
> >>> >>
> >>> >>
> >>> >> Joe Walker-3 wrote:
> >>> >> >
> >>> >> > On Feb 8, 2008 2:49 PM, Hani Suleiman
> <hani@...> wrote:
> >>> >> >
> >>> >> >> On Feb 8, 2008, at 9:42 AM, Joe Walker wrote:
> >>> >> >>
> >>> >> >> >
> >>> >> >> > I posted some time ago for reasons why anyone would want
> >>> >> to do that.
> >>> >> >> > Can you tell me more? POST works through NTLM doesn't it?
> >>> >> >> >
> >>> >> >> > The reason I got rid if it (and pollMethod) is that DWR
> >>> >> only treats
> >>> >> >> > them as a hint anyway. There are many cases where it
> >>> decides that
> >>> >> >> > it's going to ignore your request. For example, script
> >>> >> tags must use
> >>> >> >> > GET, anything with a input[type=file] must use a POST,
> >>> >> etc, etc. By
> >>> >> >> > removing the option we admit that we can't do what
> >>> you might have
> >>> >> >> > thought we could.
> >>> >> >> >
> >>> >> >> > I'm happy to put something back in, but I would
> >>> prefer to either
> >>> >> >> > demonstrate that you don't need it, or find a way to
> >>> >> automatically
> >>> >> >> > detect your situation and work around it.
> >>> >> >>
> >>> >> >> The problem we have is that we allow for NTLM to be turned
> >>> >> on/off on
> >>> >> >> the fly, and users (well, this only applies to admin
> >>> users, who can
> >>> >> >> 'override' NTLM) end up with their requests not working.
> >>> >> It's an issue
> >>> >> >> with NTLM that IE will in certain situations (such as when
> >>> >> you switch
> >>> >> >> it on/off) it will simply stop sending any POST body data.
> >>> >> >>
> >>> >> >> However, since we're now using dwr in some fairly crucial
> >>> >> admin pages,
> >>> >> >> we need them to keep working even when the user does
> >>> >> something stupid
> >>> >> >> like that, and having the requests on those pages be GETs
> >>> >> works around
> >>> >> >> it.
> >>> >> >>
> >>> >> >> Not very compelling I know, but it does save me many
> >>> >> >> headaches...Though having said that, I did find a
> >>> >> workaround, which to
> >>> >> >> do this after dwr is loaded:
> >>> dwr.engine.transport.xhr.httpMethod =
> >>> >> >> 'GET';
> >>> >> >
> >>> >> >
> >>> >> > So my take is that you're probably a bit of a corner case,
> >>> >> and that we
> >>> >> > should document the workaround, but that this is a case
> >>> >> where less is
> >>> >> > more.
> >>> >> > Anyone: Feel free to argue.
> >>> >> >
> >>> >> > Joe.
> >>> >> >
> >>> >> >
> >>> >>
> >>> >> --
> >>> >> View this message in context:
> >>> >>
> http://www.nabble.com/Verb-gone-missing--tp15356069p25640507.html
> >>> >> Sent from the DWR - Dev mailing list archive at Nabble.com.
> >>> >>
> >>> >>
> >>> >>
> >>>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: dev-unsubscribe@...
> >>> >> For additional commands, e-mail: dev-help@...
> >>> >>
> >>> >
> >>> >
> >>> >
> >>>
> ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: dev-unsubscribe@...
> >>> > For additional commands, e-mail: dev-help@...
> >>> >
> >>> >
> >>> >
> >>>
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Verb-gone-missing--tp15356069p25654579.html
> >>> Sent from the DWR - Dev mailing list archive at Nabble.com.
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@...
> >>> For additional commands, e-mail: dev-help@...
> >>>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: dev-unsubscribe@...
> >>For additional commands, e-mail: dev-help@...
> >>
> >
>
> --
> View this message in context:
> http://www.nabble.com/Verb-gone-missing--tp15356069p25708278.html
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...