Java SPNego bug #167

WiktorS · 2014-11-20T08:38:20Z

I think there is a bug introduced in waffle 1.7.

AuthorizationHeader.isNtlmType1PostAuthorizationHeader() returns true for both SPNego message types (NegTokenInit or NegTokenArg), what causes call of auth.resetSecurityToken() inside NegotiateSecurityFilterProvider.doFilter().

Negotiation looses context when NegotiateSecurityFilterProvider receives NegTokenArg message.

This might be problem inside my code since I am implementing my own HttpServletRequest and HttpServletResponse interfaces, but it works in waffle 1.5 and 1.6.

WS

dblock · 2014-11-20T12:13:13Z

You should be able to turn this into a spec, which will make it easy to fix. Thanks for reporting it.

hazendaz · 2014-11-23T07:53:37Z

Reviewing changes logs.

Waffle 1.5 did not support SPNego.
Support was added in 1.6 as PR Spnego #40.
In version 1.7, PR Detect also NegTokenArg packet. #76 was added. That seems to be the clue for this issue.

Support for SPNego was added by @AriSuutariST. Possibly this user can assist on this.

WiktorS · 2014-11-24T08:10:54Z

Will try to write test for this issue, but I need some time to do it since I am no too experienced with Java projects.

ASunc · 2014-11-24T08:20:40Z

Hi,

We are using waffle.apache.NegotiateAuthenticator valve at several sites and the SPNego stuff seems to work ok with it. However, I must admit that code I added only detects that those packets are related to authentication and should not be passed to application (for example a servlet). I'm not familiar how Waffle processes the packet after it has been classfied as authentication data, but it makes sense that NegTokenArg might require different processing as it is related to previous NegTokenInit.

hazendaz · 2015-12-13T18:39:57Z

@ WiktorS is it possible to verify if this still exists and based on your last comment I'm hoping last year has seen great growth for you with java. If so, we would love to see a PR for this issue if it still exists.

WiktorS · 2015-12-16T08:00:50Z

Totally forgot about this issue... I will verify this within few days

OlivierJaquemet · 2016-03-23T17:06:19Z

We are observing the same issue and I have a reproduction procedure using ajax request and Internet Explorer :

The symptoms :

an SPNEGO authentication is properly performed on first nonxhr request
subsequent nonxhr request are properly handled and authenticated
then an ajax request occurs :
using POST,
with a Content-Length: 0 ,
and IE behaviors is to resend the Authorization: Negotiate for this request

This leads to an invalid 401 Unauthorized being sent.
IE may output the following error in its console :
SCRIPT7002: XMLHttpRequest: Network Error 0x2ef3, Could not complete the operation due to error 00002ef3
This problem did not occur when we were using waffle 1.5

To reproduce :

You can easily reproduce this problem with the following HTML test page:

<!DOCTYPE html>
<html>
<head><script src="https://code.jquery.com/jquery-1.12.0.min.js"></script></head>
<body>
  <button onclick="jQuery.ajax({ url:document.location.href, type:'POST' });">
   Click me to send empty ajax request                                                               
  </button>
</body>
</html>

Put this page on any site for which authentication is handled by waffle.
Use wireshark or any real sniffer to observe the 401 (not the IE11 network panel in which the ajax request will appear has abandonned)

ASunc · 2016-03-24T06:16:55Z

With waffle 1.5 messages with SPNEGO auth ended up into application servlet calls, that's why I first spotted that some functionality was missing. I think that stuff added in 1.6 should be quite ok, but NegTokenArg stuff added in 1.7 might be the problem as the method to detect the authentication packet is not really solid (there is no signature that could be used for detection).

Could you try with 1.6, just to see if it works in this situation ?

We have 1.7 in use in production sites, but there might be no zero-length ajax requests in our application.

OlivierJaquemet · 2016-03-24T08:01:58Z

@AriSuutariST I'll do a test with 1.6 during the hours to come.

In the mean time, you can also test an ajax request on your site with the simple html file I gave above which I guarantee will not modify anything:)
And if you cannot deploy this file, you can also test in the IE developper console by running this code :

var jq = document.createElement('script');
jq.src = "https://code.jquery.com/jquery-1.12.0.min.js";
document.getElementsByTagName('head')[0].appendChild(jq);

// ... give time for script to load, then type.
jQuery.noConflict();
jQuery.ajax({ url:document.location.href, type:'POST' });

ASunc · 2016-03-24T08:20:07Z

Just tested on production site, your javascript example works there (HTTP 200 response) with Waffle 1.7.4, Win 2012 R2, Tomcat 7, JDK 1.8.

OlivierJaquemet · 2016-03-24T08:22:03Z

Damn. Did you test with IE ?

ASunc · 2016-03-24T08:28:01Z

Yes, Win 10 + IE11. I'm using Valve in tomcat like this:

<Valve className="waffle.apache.NegotiateAuthenticator" principalFormat="fqn" roleFormat="both" />

But please check with 1.6 if you can.

OlivierJaquemet · 2016-03-24T08:31:33Z

I'll do a test as soon as I can today. but I have other pending tasks to do before.
(your valve configuration did not appear in your comment)

ASunc · 2016-03-24T08:55:02Z

@dblock To avoid resetSecurityToken() mentioned in first comment, I think waffle needs extra method to AuthorizationHeader, maybe something like isNtlmType1PostAuthorizationHeaderContinuation() as original design does not (to my understanding) handle cases where multi-packet negotiation is used for authorization.

That new method could return true when we have NegTokenArg header, false for all other cases.
NegotiateSecurityFilterProvider could then check that.

OlivierJaquemet · 2016-03-24T10:40:35Z

I just tested my test.html file on previous version :

1.6 -> same bug
1.5 -> no problem

One important difference regarding your setup @AriSuutariST , I'm not using waffle-tomcat but the NegotiateSecurityFilter available in waffle-jna.

I am really willing to help you on this matter, for example by modifying the source code (specially waffle.util.AuthorizationHeader) to test whatever implementation you might have, but I am not familiar enough with the protocol to perfom any modification without risking other regression.

ASunc · 2016-03-24T10:45:16Z

I was hoping that 1.6 would work. Now I'm out of ideas how to fix this :-(

OlivierJaquemet · 2016-03-24T10:56:47Z

@hazendaz said in in first comment that support was added in 1.6 as PR #40... wouldn't it be logical that this is the source of problem ?
As I understand, the problem seems to be in the behavior verified by unittest testIsSPNegoPostAuthorizationHeader which should not be true for ajax request (though I understand my use case differs from the initial report of @WiktorS )

ASunc · 2016-03-24T11:04:10Z

I just configured by development system with filter instead of valve. Works ok... I wonder what is
the difference between our environments.

For authentication there is no difference if the request is ajax or not. The problems is somewhere else.

ASunc · 2016-03-24T11:05:59Z

Maybe the zero Content-Length confuses some layer in Waffle to think that request is authentication when it is not.

ASunc · 2016-03-24T11:18:40Z

I was able to reproduce the original issue now. I'll try to fix it first.

dblock · 2016-03-24T12:37:58Z

@AriSuutariST since you can reproduce I think you're in the best place to fix it, looking forward to a pull request.

hazendaz · 2016-03-24T12:45:35Z

When a PR comes along...please submit to master and 1.7 branch. I'll cut a fix for both so java 6 users are not left out.

Sent from Outlook Mobile

On Thu, Mar 24, 2016 at 5:38 AM -0700, "Daniel Doubrovkine (dB.) @dblockdotorg" [email protected] wrote:

@AriSuutariST since you can reproduce I think you're in the best place to fix it, looking forward to a pull request.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#167 (comment)

ASunc · 2016-03-24T12:45:58Z

I'm currently debugging it and trying to obtain better understanding what is really going on. Anyway, this is going to take some days so don't hold your breath yet :-)

ASunc · 2016-03-24T13:23:21Z

I see why this occurs with zero-length POST now. AuthorizationHeader.isNtlmType1PostAuthorizationHeader() returns false if contentLength() != 0.
This causes bug not to be visible if POST contains any data.

OlivierJaquemet · 2016-03-24T14:24:33Z

This is what I was trying to tell when i was reffering to testIsSPNegoPostAuthorizationHeader, I'm sorry I did not made myself clear enough.
Tell me if I can help you in any way ! As I have a working environement with an easy reproduction I can quickly verify any lead you might have.

I just did a debugging session with my reproduction step, and it seems to me the problem starts in waffle.servlet.NegotiateSecurityFilter.doFilterPrincipal with the following code :
https://github.com/dblock/waffle/blob/5cba5c6b2ef7821f2f6c9134f9965c9164304a01/Source/JNA/waffle-jna/src/main/java/waffle/servlet/NegotiateSecurityFilter.java#L225-L228

    if (this.providers.isPrincipalException(request)) {
        // the providers signal to authenticate despite an existing principal, eg. NTLM post
        return false;
    }

The implementation of waffle.servlet.spi.NegotiateSecurityFilterProvider.isPrincipalException relies on method AuthorizationHeader.isNtlmType1PostAuthorizationHeader to consider that a new authentication must be performed even though the existing one is perfectly valid and as far I know there is no reason to attempt a new one :

https://github.com/dblock/waffle/blob/5cba5c6b2ef7821f2f6c9134f9965c9164304a01/Source/JNA/waffle-jna/src/main/java/waffle/servlet/spi/NegotiateSecurityFilterProvider.java#L111-L117

public boolean isPrincipalException(final HttpServletRequest request) {
    final AuthorizationHeader authorizationHeader = new AuthorizationHeader(request);
    final boolean ntlmPost = authorizationHeader.isNtlmType1PostAuthorizationHeader();
    LOGGER.debug("authorization: {}, ntlm post: {}", authorizationHeader, Boolean.valueOf(ntlmPost));
    return ntlmPost;
}

ASunc · 2016-03-24T14:52:04Z

It is important to detect which post as only for authentication - otherwise your application starts receiving spurious zero-length post-requests. I think that it was to reason why I started digging into SPNEGO headers in first place.

I think that original idea in isNtlmType1PostAuthorizationHeader() is this filtering, but I'm not sure. I just mimicked same design for SPNEGO headers. But now the method is used for controlling in resetSecurityToken() calls also, which might be wrong. If the token is bound to connection is there ever a situation where it should be reset (as it is 'reset' for new connections, I suppose).

So would the correct fix be to:

never reset token like done now
filter those post requests from application which have no data and are just authentication

The last one is actually not that simple. It seems that browser sends post data
with last NegTokenArg packet (there can be multiple). And data can be empty or not.

ASunc · 2016-03-24T15:37:37Z

@OlivierJaquemet I'll be away for a few days, but I'll continue digging into this (unless it has been solved before I get back).

OlivierJaquemet · 2016-03-24T15:48:54Z

Thank for your explanation of all aspects of this subject @AriSuutariST.
There is no hurry as far as I am concerned, I have implemented a (kludge) workaround above the waffle filter for our use case. An official fix in waffle would definitely be better so everybody can benefit from it, including us. So If I can help your later on this matter, i'll be there.

ASunc · 2016-04-01T09:08:14Z

I have been thinking how to get this working in more robust way. Currently isNtlmType1PostAuthorizationHeader() logic is used for two things (based on browsing the source code):

resetSecurityToken is called for connectionId
if POST/PUT doesn't contain data (ie. browser is sending only authentication information) request doesn't go to application, it is processed internally in waffle code only.

The later was the original reason for me to start working with SPNEGO stuff. I didn't realize the first case at the time.

I think too that @OlivierJaquemet is correct here, resetSecurityToken call is completely unnecessary. This is because authentication is per each connection. For new connection, no resetting is needed as it is already in "reset" state. For old connection, server / browser will not renegotiate it. So that part of current code could just be removed without any harm.

This leaves filtering out POST/PUTs which are only for authentication (see rfc4559 chapter 6 for details). Maybe instead of trying to decode data in Authorization header isNtlmType1PostAuthorizationHeader() could be implemented by just checking if Authorization header starts with "Negotiate" word and content-length is zero.

Please comment, I'll make the changes if this makes sense to others.

OlivierJaquemet · 2016-04-04T12:39:16Z

ah, that explains a lot. I learned a long time ago to never test spnego(ntlm/kerberos) with localhost as it never behave in the same way.
Good to know you found the explanation of this discrepancy with my observations !

@dblock your blog post is very interesting, however it is about NTLM. So if I correctly understand the situation, resetting connexion in the NegotiateSecurityFilter should only be done for NTLM authentication, not Kerberos. So when a Authorization: Negotiate ... header is sent, it should probably only trigger a reset IF the negotiate value is an NTLMSSP_NEGOTIATE,
If it is so, then the problem might be in the following code where isSPNegoMessage should be something lik isNtlmSPNegoMessage (which does not "yet" exist :p) :
https://github.com/dblock/waffle/blob/26d10b9a5364f3a0726328bd00f30a7d3f714e75/Source/JNA/waffle-jna/src/main/java/waffle/util/AuthorizationHeader.java#L164

What do you think ?

ASunc · 2016-04-04T12:54:14Z

Resetting is ok for kerberos case also, but we should be careful to do it only when authentication starts. Now reset is called again if authentication needs multiple passes between browser and server.

Btw, I'm not sure if I can test NTLM protocol, my systems seem to use kerberos always.

OlivierJaquemet · 2016-04-04T13:01:06Z

To test SPNEGO with NTLM and not kerberos :

edit your hosts file on your client machine and add any dumb alias for your remote server (for which no SPN will be declared) and save
access this alias

ASunc · 2016-04-05T10:29:43Z

My solution to stop zero-length post leaking to application in PR #76 is wrong as isNtlmType1PostAuthorizationHeader() is expected to return true only packets that start new authentication. NegTokenArg never occurs as first packet. NegTokenInit processing should be OK, as it behaves same way as NTLM type 1 packet.

The problem that #76 was trying to address must be handled in different way (don't know how yet).

Also, the case where application deliberately sends zero-length post must be tested (as it seems to be difficult to separate if browser is starting new authentication or application is sending zero-lenght post).

dblock · 2016-04-05T11:16:25Z

@AriSuutariST Are you saying we should revert #76?

ASunc · 2016-04-05T11:28:09Z

Partly, yes. Not completely, because it will cause problems when authentication headers using NegTokenArg data are used with POST - they leak to application, confusing it.

NegTokenArg stuff is difficult to test, I wish I knew how to trigger such negotiation that they are used. I have it occurring on large production system, but not on my test environment. On my test environment, authentication completes after first GET/POST having "Authorize: Negotiate ...." header set.

However, I don't object reverting #76, it would fix the original issue in this thread.

ASunc · 2016-04-05T12:52:45Z

These issues seem to be two separate ones. Original one about negotiation loosing context when NegTokenArg and the one reported by @OlivierJaquemet with zero-length ajax post (where packet trace shows only NegTokenInit). When IE uses SPNEGO and has already autheticated with previous requests, it seems to blindly send Negotiate header with post. It is correct that in such case Waffle calls resetSecurityToken. Waffle even handles to Negatiate data OK after that, but fails on NegotiateSecurityFilterProvider:159 where it checks if it should sent SC_UNAUTHORIZED or not.
Changing this to rely only on securityContext.isContinue() makes things work - I tested with SPNEGO and NTLM both.

I think that idea behind this in IE (sending the authentication info with post data) is performance optimization, it avoids unncessary round-trip with content-length=0 when it knows that SPNEGO auto should be valid based on previous GETs/POSTs.

fanste · 2016-05-02T21:29:30Z

OliverJaquemet pointed me to this issue, as I have a similar error in IE11. I've applied both fixes (338, 339) but the error sill occurs. Let me explain it and please tell me, if it might be related or not.

I'm using waffle-jna (servlet, JSF) to do single-sign-on on our company applications. Everything seems to work until a XHR file upload is performed. IE11 seems to send a special request that should test, if authentication is required (no post data but content length != 0). This is done to not waste bandwidth as the uploaded data is thrown away if auth is required.

I don't have the log with me (I will confirm this tomorrow) but as far as I remember it ends in SEC_I_CONTINUE_NEEDED followed by the message previous authenticatd user. I have to take a look into the client-server communication using whireshark how many round-trips are made. After that the request is forwared to the application which tries to read the post data. This results in a read timeout as no data is available.

I will try to gather more information tomorrow.

ASunc · 2016-05-03T05:50:32Z

Really no POST data but Content-Length > 0 ? Because all other special authentication stuff related to post works so that POST has Content-Length: 0 but carries authentication headers. If Content-Length indicates that there should be data and there isn't I think that is not IE optimization, but something goes so wrong that IE negotiation just drops dead and it closes the connection.

These are sometimes hard to reproduce by others, maybe sharing wireshark traffic dumps of problematic cases would be helpful.

fanste · 2016-05-03T08:07:21Z

You are right. I've missed one request which is the zero-length POST request. It returns with 401, IE responds but fiddler tells me, that no data is sent. Additionally the second request sometimes doesn't appear in my log...
Without the zero-length POST but directly sending the data everything works.
Too bad, that I cant find the page anymore were I've read about that optimization thing...

I will get you a traffic dump.

ASunc · 2016-05-03T08:12:19Z

@fanste Are you using Tomcat, with valve or filter ?

fanste · 2016-05-03T08:31:29Z

I'm using waffle as a filter on JBoss 7.1.3 (waffle is added as a module inside JBoss).

Some more findings (until dump is made):

zero-length POST is made and is correctly recognized by waffle. 401 is sent back to the client (server side state is continue required = true)
next request arrives with content-length > 0 and the authentication header. Waffle reports it as previously authenticated Windows user and forwards the request to the application. But IE doesn't include the POST data. Exactly 2 minutes later the application throws an exception as it can't read any data.

10:14:45,285 INFO  [stdout] (http-/0.0.0.0:8080-4) ~~~~~~~~~~~~~~~ [START] POST /Chain/pages/crud/edit/purpose/rofa.jsf (0)
10:14:45,287 DEBUG [waffle.servlet.NegotiateSecurityFilter] (http-/0.0.0.0:8080-4) POST /Chain/pages/crud/edit/purpose/rofa.jsf, contentlength: 0
10:14:45,290 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) authorization: Negotiate YH0GBisGAQUFAqBzMHGgMDAuB[...], ntlm post: true
10:14:45,294 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) security package: Negotiate, connection id: 127.0.0.1:59327
10:14:45,297 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) token buffer: 127 byte(s)
10:14:45,303 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) continue token: oYIBDzCCAQugAwoBAaEMBgorBgEEAYI3A[...]
10:14:45,306 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) continue required: true
10:14:45,308 INFO  [stdout] (http-/0.0.0.0:8080-4) ~~~~~~~~~~~~~~~ [END] POST /Chain/pages/crud/edit/purpose/rofa.jsf (0)

10:14:45,316 INFO  [stdout] (http-/0.0.0.0:8080-4) ~~~~~~~~~~~~~~~ [START] POST /Chain/pages/crud/edit/purpose/rofa.jsf (116611)
10:14:45,321 DEBUG [waffle.servlet.NegotiateSecurityFilter] (http-/0.0.0.0:8080-4) POST /Chain/pages/crud/edit/purpose/rofa.jsf, contentlength: 116611
10:14:45,324 DEBUG [waffle.servlet.spi.NegotiateSecurityFilterProvider] (http-/0.0.0.0:8080-4) authorization: Negotiate oXcwdaADCgEBoloEWE5UTE1[...], ntlm post: false
10:14:45,327 DEBUG [waffle.servlet.NegotiateSecurityFilter] (http-/0.0.0.0:8080-4) previously authenticated Windows user: <DOMAIN>\<USER>
10:16:46,340 SEVERE [org.primefaces.webapp.MultipartRequest] (http-/0.0.0.0:8080-4) Error in parsing fileupload request: org.apache.commons.fileupload.FileUploadException
        at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362) [commons-fileupload-1.3.jar:1.3]
        at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115) [commons-fileupload-1.3.jar:1.3]
        at org.primefaces.webapp.MultipartRequest.parseRequest(MultipartRequest.java:57) [primefaces-5.2.jar:5.2]
        at org.primefaces.webapp.MultipartRequest.<init>(MultipartRequest.java:51) [primefaces-5.2.jar:5.2]
        at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:91) [primefaces-5.2.jar:5.2]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-luk1.jar:]
        at webapp.servlet.filter.LoggingFilter.doFilter(LoggingFilter.java:69) [webapp-basics-1.2.18.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-luk1.jar:]
        at webapp.servlet.filter.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:51) [webapp-basics-1.2.18.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.9.Final.jar:2012-08-06 19:12]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-luk1.jar:]
        at waffle.servlet.NegotiateSecurityFilter.doFilterPrincipal(NegotiateSecurityFilter.java:251) [waffle-jna-1.8.2-SNAPSHOT.jar:1.8.2-SNAPSHOT]
        at waffle.servlet.NegotiateSecurityFilter.doFilter(NegotiateSecurityFilter.java:110) [waffle-jna-1.8.2-SNAPSHOT.jar:1.8.2-SNAPSHOT]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-luk1.jar:]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-luk1.jar:]
        [...]

fanste · 2016-05-03T10:00:48Z

Here are the traffic dumps. I hope they provide the information you need.

success overview

record no 146

record no 148

record no 151

record no 153

record no 298

failed overview

record no 2497

record no 2500

ASunc · 2016-05-03T10:15:49Z

This looks different than the problems in this issue, not related to SPNEGO/Kerberos, as this is all NTLM authentication. It would be nice to see rest of the packets in failed overview, now there is only the initial zero-length post and server response.

OlivierJaquemet · 2016-05-03T10:20:00Z

@fanste Given your capture, and contrary to what I initially thought and stated, you migh be observing the same issue I reported in #346
As a workaround if you properly configure Keberos authentication (double check the spn configuration), you should not be impacted anymore (as long as you have the patch #338 and #339).

fanste · 2016-05-03T11:17:34Z

@AriSuutariST I can't give you more packets as the communication stops at that point. Within another capture there is one more package that delivers the 500 status code back to the client which indicates the read timeout (2 minutes) of the upload.
I'm sorry that I forgot to mention the used mechanism (NTLM).

@OlivierJaquemet Alright :D Then I have to find out how Kerberos is configured in waffle and how I'm able to use this within our company.

dblock added the bug? label Nov 20, 2014

This was referenced Apr 6, 2016

Don't allow SPNEGO NegTokenArg to start re-authentication. #338

Merged

Use only securityContext.isContinue() to decide if SC_UNAUTHORIZED re… #339

Closed

OlivierJaquemet mentioned this issue May 2, 2016

Internet Explorer bodyless POST optimization with SPNEGO header and accept-incomplete not handled #346

Open

hazendaz referenced this issue in hazendaz/waffle Jan 29, 2017

Alternative solution to fix #59 and possibly #167

729a764

tjstuart mentioned this issue Apr 5, 2018

Use only securityContext.isContinue() to decide if SC_UNAUTHORIZED re… #609

Merged

hazendaz added a commit that referenced this issue Apr 8, 2018

Alternative solution to fix #59 and possibly #167

7dac0a3

hazendaz added a commit that referenced this issue Jun 30, 2018

Alternative solution to fix #59 and possibly #167

59e221e

joergmattes mentioned this issue Oct 18, 2019

waffle-shiro: problems with bodyless (zero-length) IE POST #806

Open

hazendaz added a commit that referenced this issue Sep 7, 2020

Alternative solution to fix #59 and possibly #167

e2af31f

hazendaz added a commit that referenced this issue Jun 27, 2022

Alternative solution to fix #59 and possibly #167

c8e2a1f

hazendaz added a commit that referenced this issue Jul 24, 2022

Alternative solution to fix #59 and possibly #167

d87d1ae

hazendaz added a commit that referenced this issue Jul 24, 2022

Alternative solution to fix #59 and possibly #167

7409f2b

hazendaz added a commit that referenced this issue Mar 26, 2023

Alternative solution to fix #59 and possibly #167

3beb803

hazendaz added a commit that referenced this issue Jan 21, 2024

Alternative solution to fix #59 and possibly #167

157800e

Java SPNego bug #167

Java SPNego bug #167

Comments

WiktorS commented Nov 20, 2014

dblock commented Nov 20, 2014

hazendaz commented Nov 23, 2014

WiktorS commented Nov 24, 2014

ASunc commented Nov 24, 2014

hazendaz commented Dec 13, 2015

WiktorS commented Dec 16, 2015

OlivierJaquemet commented Mar 23, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

ASunc commented Mar 24, 2016

ASunc commented Mar 24, 2016

dblock commented Mar 24, 2016

hazendaz commented Mar 24, 2016

ASunc commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Mar 24, 2016

ASunc commented Mar 24, 2016

OlivierJaquemet commented Mar 24, 2016

ASunc commented Apr 1, 2016

OlivierJaquemet commented Apr 4, 2016

ASunc commented Apr 4, 2016

OlivierJaquemet commented Apr 4, 2016

ASunc commented Apr 5, 2016

dblock commented Apr 5, 2016

ASunc commented Apr 5, 2016

ASunc commented Apr 5, 2016

fanste commented May 2, 2016

ASunc commented May 3, 2016

fanste commented May 3, 2016 • edited Loading

ASunc commented May 3, 2016

fanste commented May 3, 2016 • edited Loading

fanste commented May 3, 2016

ASunc commented May 3, 2016

OlivierJaquemet commented May 3, 2016

fanste commented May 3, 2016

fanste commented May 3, 2016 •

edited

Loading

fanste commented May 3, 2016 •

edited

Loading