Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NTLM Authenentication not working #3110

Open
magreenblatt opened this issue Apr 15, 2021 · 25 comments
Open

NTLM Authenentication not working #3110

magreenblatt opened this issue Apr 15, 2021 · 25 comments
Labels
bug Bug report Framework Related to framework code or APIs help wanted Issue resolution will likely require community contributions

Comments

@magreenblatt
Copy link
Collaborator

Original report by Thomas Runkel (Bitbucket: Thomas Runkel).


Uploading a file to a minio (or S3) repo using cef >86 (js, XMLHttpRequest). is not working anymore.

(see also Forum-Thread: NTLM Authenentication not working anymore in OutOfBlinkC)

When trying to send the preflight (OPTIONS) request, there’s no authentication challenge with the proxy.

What happens is that CEF sends exactly one request, the proxy answers with a 407 Proxy Authentication Required and that's it. No second try to connect, no authentication granted.

As we found out, intercepting the network traffic seems to be the problem.

Setting |pass_though| = true in ProxyURLLoaderFactory::CreateLoaderAndStart (thx to Marshall) fixes the problem.

Could it be a workaround to make pass_through an Option?

Additional info: To make devtools work, do something like this:
bool pass_through = !request.url.SchemeIs("devtools");

@magreenblatt
Copy link
Collaborator Author

Only disable request handling for HTTP/S schemes (see issue #3110)

The --disable-request-handling-for-testing command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.

→ <<cset f3ed6619da1e (bb)>>

@magreenblatt
Copy link
Collaborator Author

Only disable request handling for HTTP/S schemes (see issue #3110)

The --disable-request-handling-for-testing command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.

→ <<cset 9b0af44ca660 (bb)>>

@magreenblatt
Copy link
Collaborator Author

Only disable request handling for HTTP/S schemes (see issue #3110)

The --disable-request-handling-for-testing command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.

→ <<cset 09ee681fc45c (bb)>>

@magreenblatt
Copy link
Collaborator Author

  • changed component from "Unclassified" to "Framework"

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


any plan to fix this issue? Because of this issue , we are stuck with CEF upgrade to latest version.

@magreenblatt
Copy link
Collaborator Author

Trial fix for CORS pre-flight requests missing headers (see issue #3110, see issue #3200)

→ <<cset e83d8d6a131a (bb)>>

@magreenblatt
Copy link
Collaborator Author

Trial fix for CORS pre-flight requests missing headers (see issue #3110, see issue #3200)

→ <<cset 147b5f55328c (bb)>>

@magreenblatt
Copy link
Collaborator Author

Trial fix for CORS pre-flight requests missing headers (see issue #3110, see issue #3200)

→ <<cset 0d6005e731a6 (bb)>>

@magreenblatt
Copy link
Collaborator Author

M95 and newer builds with the above trial fix should be available tomorrow (Wed, Nov 10). Please try that build and report back whether the problem is resolved or still reproduces for you.

@magreenblatt
Copy link
Collaborator Author

Original comment by Thomas Runkel (Bitbucket: Thomas Runkel).


tried

cef_binary_96.0.12+g147b5f5+chromium-96.0.4664.35_windows32_beta_client

still the problem.

  • w/o proxy → works fine…
  • activating proxy → not working

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


It didn't worked for me either on proxy connection.

Checked with latest v96 CEF client.

@magreenblatt
Copy link
Collaborator Author

OK, thanks for testing. Any further debugging on my end is currently blocked on a way to reproduce the issue. Someone who is able to reproduce this issue may need to debug it further. Something more may be required with CorsPreflightRequest.

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


Hi @Marshall Greenblatt

if you are on proxy internet connection just try below code on dev tool - console window and press enter

you will be able to reproduce the issue. Presence of “Authorization -token” header in below code will initiate the preflight request.

Code ::


function reqlistener()
{
console.log(this.responseTest);
}

var oReq = new XMLHttpRequest();
oReq.addEventListener("load",reqlistener);
oReq.open("GET","https://reqres.in/api/users/2");
oReq.setRequestHeader("authorization-token","dummy header");


Thanks,

Kalpesh J

@magreenblatt
Copy link
Collaborator Author

@{557058:a92737e1-4077-4f02-a0fa-4f1cc2224f72} Thanks, I’ll try that when I circle back to this issue next.

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


@{557058:2f2a2aee-b500-4023-9734-037e9897c3ab} Did you got a chance to look at it?

@magreenblatt
Copy link
Collaborator Author

Original comment by Bhushan Sonawane (Bitbucket: Bhushan Sonawane).


@marshall Greenblatt I am also facing the same error on latest cef version 95. can you please check and suggest some fix for it ?

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


Any update on this. Are we planning to fix this in the upcoming CEF release?

@magreenblatt
Copy link
Collaborator Author

This may be fixed in version 97.0.12 or newer (builds available after 1/7/22). Please test and report back if the issue is resolved for you.

@magreenblatt
Copy link
Collaborator Author

Original comment by Thomas Runkel (Bitbucket: Thomas Runkel).


Sry Marschal,

but I have to say... no improvement. Same behaviour with cef_binary_97.1.1. 😞

@magreenblatt
Copy link
Collaborator Author

I’m not able to reproduce this problem with 97.1.1.

Testing with cefclient (cefclient.exe --proxy-server=<IP>:808) and CCProxy, and using the default “guest”/”guest” credentials already configured in ClientHandler::GetAuthCredentials, the following JavaScript results in Success:

fetch('https://reqres.in/api/users/2', {
  method: 'GET',
  headers: {
    'authorization-token': 'dummy header',
  },
})
.then(response => response.json())
.then(data => {
  console.log('Success:', data);
})
.catch((error) => {
  console.error('Error:', error);
});

Using chrome://net-export/ to record the network activity I see that both the GET and OPTIONS requests are succeeding:

t=1507 [st=1507]          HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
                          --> :method: GET
                              :authority: reqres.in
                              :scheme: https
                              :path: /api/users/2
                              sec-ch-ua: "Chromium";v="98"
                              sec-ch-ua-mobile: ?0
                              authorization-token: dummy header
                              user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.0 Safari/537.36
                              sec-ch-ua-platform: "Windows"
                              accept: */*
                              origin: https://www.example.com
                              sec-fetch-site: cross-site
                              sec-fetch-mode: cors
                              sec-fetch-dest: empty
                              referer: https://www.example.com/
                              accept-encoding: gzip, deflate, br
                              accept-language: en-US,en;q=0.9
t=1508 [st=1508]       -HTTP_TRANSACTION_SEND_REQUEST
t=1508 [st=1508]       +HTTP_TRANSACTION_READ_HEADERS  [dt=280]
t=1787 [st=1787]          HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                          --> HTTP/1.1 200
                              date: Mon, 10 Jan 2022 19:00:07 GMT
                              content-type: application/json; charset=utf-8
                              x-powered-by: Express
                              access-control-allow-origin: *
                              etag: W/"118-pbdwwFo9SKNhD3Lx5iHJyngpq00"
                              via: 1.1 vegur
                              cache-control: max-age=14400
                              cf-cache-status: MISS
                              expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
                              report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=bhXTxs%2BpsFsYfdX%2FgjcVIHiJG07OtaZ9vS3kdlz5ToB4QOXQE0cNGrZgmJZpDpM%2BGvL0ODXRAYfevRyqdtWbcqQdFpvwUYBL0FITB9iUO1J8z%2B%2B%2B%2Fu0q8cv87wY%3D"}],"group":"cf-nel","max_age":604800}
                              nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
                              vary: Accept-Encoding
                              server: cloudflare
                              cf-ray: [6cb82576ee60c560 (bb)](https://bitbucket.org/chromiumembedded/cef/commits/6cb82576ee60c560)-ORD
                              content-encoding: br
                              alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400

t=1238 [st=1237]        HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
                        --> :method: OPTIONS
                            :authority: reqres.in
                            :scheme: https
                            :path: /api/users/2
                            accept: */*
                            access-control-request-method: GET
                            access-control-request-headers: authorization-token
                            origin: https://www.example.com
                            user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.0 Safari/537.36
                            sec-fetch-mode: cors
                            sec-fetch-site: cross-site
                            sec-fetch-dest: empty
                            referer: https://www.example.com/
                            accept-encoding: gzip, deflate, br
                            accept-language: en-US,en;q=0.9
t=1240 [st=1239]     -HTTP_TRANSACTION_SEND_REQUEST
t=1240 [st=1239]     +HTTP_TRANSACTION_READ_HEADERS  [dt=251]
t=1264 [st=1263]        HTTP2_STREAM_UPDATE_SEND_WINDOW
                        --> delta = 1
                        --> stream_id = 1
                        --> window_size = 65536
t=1490 [st=1489]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                        --> HTTP/1.1 204
                            date: Mon, 10 Jan 2022 19:00:06 GMT
                            content-length: 0
                            x-powered-by: Express
                            access-control-allow-origin: *
                            access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
                            vary: Access-Control-Request-Headers
                            access-control-allow-headers: authorization-token
                            via: 1.1 vegur
                            cf-cache-status: DYNAMIC
                            expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
                            report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=Xt5SMbeQPu%2F%2F7e3CZuRC%2B0o6qxTNvhg%2FijMSIPQduwC9ECtWhccu5J2d9iaw%2FrAFc7cC0YQ7b%2B1uiuNOJeYzOJGWTKEylzh9TU6zWZz2G1BkFD0AMYa9EyR7O%2Fw%3D"}],"group":"cf-nel","max_age":604800}
                            nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
                            server: cloudflare
                            cf-ray: [6cb825753be9c560 (bb)](https://bitbucket.org/chromiumembedded/cef/commits/6cb825753be9c560)-ORD
                            alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400

@magreenblatt
Copy link
Collaborator Author

The above also succeeds for me in 97.0.11, so it’s possible that I’m not testing the problem correctly. Does this issue require a specific type of proxy? Can you provide better reproduction steps?

@magreenblatt
Copy link
Collaborator Author

Original comment by Kalpesh Jain (Bitbucket: Kalpesh Jain).


hi @{557058:2f2a2aee-b500-4023-9734-037e9897c3ab}

I tested with CEF Client V - 97.1.10 and could still see the problem.

@magreenblatt
Copy link
Collaborator Author

Original comment by Lee Davis (Bitbucket: Lee Davis).


CEF: cef_binary_102.0.3+g53d4ce9+chromium-102.0.5005.40

We are experiencing this same issue on Windows and Mac and doesn’t seem limited to NTLM Auth. However, it is limited only to our debug binaries. Release binaries are fine so far. We’re not sure what to make of this and this does hamper our ability to debug other issues.

robincarlisle pushed a commit to robincarlisle/cef that referenced this issue Apr 28, 2023
…mbedded#3110)

The `--disable-request-handling-for-testing` command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.
filipnavara pushed a commit to emclient/cef that referenced this issue Dec 26, 2023
…mbedded#3110)

The `--disable-request-handling-for-testing` command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.
filipnavara pushed a commit to emclient/cef that referenced this issue Dec 26, 2023
…mbedded#3110)

The `--disable-request-handling-for-testing` command-line flag would previously
disable handling of all schemes, including custom schemes and internal schemes
such as devtools.
@magreenblatt
Copy link
Collaborator Author

This may work with CEF Chrome runtime.

@magreenblatt magreenblatt added the help wanted Issue resolution will likely require community contributions label Jul 8, 2024
@segevfiner
Copy link

It seems like this is still happening. Seems like when the first request to a domain is a CORS preflight, it doesn't authenticate to the proxy. Sending a non-preflighted request, makes further requests to the domain work as they do use the cached credentials.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug report Framework Related to framework code or APIs help wanted Issue resolution will likely require community contributions
Projects
None yet
Development

No branches or pull requests

2 participants