Open jnweiger opened 2 years ago
{"reqId":"4f35cc93-12df-4d0c-889f-4690189d7a1d","level":0,"time":"2021-10-13T11:17:36+00:00","remoteAddr":"2.247.255.38","user":"--","app":"webdav","method":"PROPFIND","url":"\/remote.php\/webdav\/","message":"Exception: HTTP\/1.1 401 No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured: {\"Exception\":\"Sabre\\DAV\\Exception\\NotAuthenticated\",\"Message\":\"No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured\",\"Code\":0,\"Trace\":\"#0 \\/var\\/www\\/owncloud\\/lib\\/composer\\/sabre\\/event\\/lib\\/WildcardEmitterTrait.php(89): Sabre\\DAV\\Auth\\Plugin->beforeMethod()\n#1 \\/var\\/www\\/owncloud\\/lib\\/composer\\/sabre\\/dav\\/lib\\/DAV\\/Server.php(456): Sabre\\DAV\\Server->emit()\n#2 \\/var\\/www\\/owncloud\\/lib\\/composer\\/sabre\\/dav\\/lib\\/DAV\\/Server.php(253): Sabre\\DAV\\Server->invokeMethod()\n#3 \\/var\\/www\\/owncloud\\/lib\\/composer\\/sabre\\/dav\\/lib\\/DAV\\/Server.php(321): Sabre\\DAV\\Server->start()\n#4 \\/var\\/www\\/owncloud\\/apps\\/dav\\/appinfo\\/v1\\/webdav.php(66): Sabre\\DAV\\Server->exec()\n#5 \\/var\\/www\\/owncloud\\/remote.php(165): require_once('\\/var\\/www\\/ownclo...')\n#6 {main}\",\"File\":\"\\/var\\/www\\/owncloud\\/lib\\/composer\\/sabre\\/dav\\/lib\\/DAV\\/Auth\\/Plugin.php\",\"Line\":154}"}
That's fishy, maybe also a problem in the client ... cc @TheOneRing
The error happens only when actually switching user duing the oauth flow. All fresh logins or authorizations of already logged in users work fine.
Not a 100% regression in oauth2-0.5.1-rc1:
But not reproducable with 0.4.4 -- the client always authenticates correctly.
Probably unrelated to ldap.
same with demo.owncloud.com
But no ldap on demo.owncloud.com
I'd like to have a look at:
curl 'https://demo.owncloud.com/index.php/apps/oauth2/authorize?response_type=code&client_id=xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69&redirect_uri=http://localhost:49402&code_challenge=dNgaS41LpVnVPllvoJoCbjwXLq0h3YB083towjNzJCE&code_challenge_method=S256&scope=openid%20offline_access%20email%20profile&prompt=select_account%20consent&state=pzaqhllYJFs-FaaJ1rBKG1kzjp_GtmJsG_goSgiQi3M%3D' \
-H 'authority: demo.owncloud.com' \
-H 'pragma: no-cache' \
-H 'cache-control: no-cache' \
-H 'upgrade-insecure-requests: 1' \
-H 'origin: null' \
-H 'content-type: application/x-www-form-urlencoded' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_6_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36 Edg/89.0.774.63' \
-H 'accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9' \
-H 'sec-fetch-site: same-origin' \
-H 'sec-fetch-mode: navigate' \
-H 'sec-fetch-user: ?1' \
-H 'sec-fetch-dest: document' \
-H 'accept-language: en-GB,en;q=0.9,en-US;q=0.8,de;q=0.7' \
-H 'cookie: oc_sessionPassphrase=DytGUUaR%2FUi%2BKZqI0V741ZxaD71ApSmoM1RuMJUWeYpw6HCUsyWDEeBLVwHApiz5KQ30xc%2BdnL2tszQUYmW2hOI546drGtDl5Az5AmbgHPU67Xi%2B4BgztZK%2B6U5I4xkw; ocnozvk1taih=mek8gv5l398040cofqi130p8g2' \
--data-raw 'requesttoken=JC43dhV%2BPBQjUxo9QyMHED0kdl5zDixYAj83DDFzFmE%3D%3AcTS0t%2BOWn6MPvIAVpkFi1yU0TKnVsKCSC84fkT%2BnmNY%3D' \
--compressed
location: http://localhost:49402?code=IQxEaNoUyeVJQXRaDn1YPF9hdsXpyYXYFkOjvU45xHHmxTAfh9WO0on6V6ghot4v&state=pzaqhllYJFs-FaaJ1rBKG1kzjp_GtmJsG_goSgiQi3M%3D
(difference with/without user change?)
Code seems to fail in https://github.com/owncloud/oauth2/blob/4ab10b07e8d5d1a361f643957d640ed1dd126541/lib/Controller/OAuthApiController.php#L168-L171
It seems you're trying to use the S256 challenge method without a code verifier. That's why the method fails. (https://github.com/owncloud/oauth2/blob/4ab10b07e8d5d1a361f643957d640ed1dd126541/lib/Db/AuthorizationCode.php#L77)
It's likely a bug with the user switching. If the rest of the flow is working fine, my guess is that we're either checking the code of a different user or we're switching the code challenge method somewhere when we switch the user. I haven't checked the code in depth, so I might be wrong.
@michaelstingl
curl 'https://oc1080-oauth2-051-rc1-20211012.jw-qa.owncloud.works/index.php/apps/oauth2/authorize?response_type=code&client_id=xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69&redirect_uri=http://localhost:33883&code_challenge=oAR2P54YPVtLAzfkvV6jo6sjVEaveOntbffTVC4jsG8&code_challenge_method=S256&scope=openid%20offline_access%20email%20profile&prompt=select_account%20consent&state=dQ7OwFr8-8C3WiyNYsyBCNQ5ADuzFXwaXSanyO8HVw4%3D'
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0'
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
-H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Content-Type: application/x-www-form-urlencoded'
-H 'Origin: null' -H 'Connection: keep-alive'
-H 'Cookie: ocl3ipw65wf5=lkievbam3q9jk2kjs6h7p97uep; oc_sessionPassphrase=1e3f1aK0zwEGDNvVfySts3UM119vVrRO4%2BKb9iiWvH8ipUoA%2B1a34ru6VyV5bxD01Gg3rS3K5vUoRfO9B5jhyeWxKFvD98lge6Aflv8T8PJ9dMfVcoVL1LZZA6maHd1W; oc1005dmthm5=306itih7c3714nfk8t1t6i72gn'
-H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: same-origin' -H 'Sec-Fetch-User: ?1'
-H 'DNT: 1' -H 'Sec-GPC: 1'
--data-raw 'requesttoken=Pil%2BNwY5EyAsNHQTSFxXMFMLP384GlYpG1QSOQszHSg%3D%3AjF%2BNLvjGkxGT869fcNT%2Fq%2B2a%2F8xwDXpO8V1QPavPBdg%3D'
HTTP/1.1 303 See Other
Date: Thu, 14 Oct 2021 14:35:36 GMT
Server: Apache/2.4.41 (Ubuntu)
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Security-Policy: default-src 'none';manifest-src 'self';script-src 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self';connect-src 'self';media-src 'self'
Location: http://localhost:33883?code=9OUPd588aaM1WguE5tp5CpUqI5Au6YFmg2SZS3QLSbAHnjytZQkCx7VErqXHMhnF&state=dQ7OwFr8-8C3WiyNYsyBCNQ5ADuzFXwaXSanyO8HVw4%3D
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
20211014_1644_owncloud.log.0.zip
curl 'https://oc1080-oauth2-051-rc1-20211012.jw-qa.owncloud.works/index.php/apps/oauth2/authorize?state=-NuSbdb3dZqX5fjUnSbRxo960Jqw7--Dhzc7rf06p94=&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A45333&client_id=xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69'
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0'
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' --compressed
-H 'Content-Type: application/x-www-form-urlencoded' -H 'Origin: null' -H 'Connection: keep-alive'
-H 'Cookie: ocl3ipw65wf5=lkievbam3q9jk2kjs6h7p97uep; oc_sessionPassphrase=vXd9Fqwx2IEeqBNFtP9%2FeZgRTpapN5IRD0KdiGSS%2FhjthUKb8mCG9Ot4S4Nk7Mzb%2FQJcBjJmnZiJPkeAbSh8Fwr65nQMnY2%2B0pIppXMiaiiSScYb94b1Xwqu7S33Ekcf; oc1005dmthm5=8oabriheb1jjo877qgaqpdgp3j'
-H 'Upgrade-Insecure-Requests: 1' -H 'Sec-Fetch-Dest: document' -H 'Sec-Fetch-Mode: navigate' -H 'Sec-Fetch-Site: same-origin' -H 'Sec-Fetch-User: ?1'
-H 'DNT: 1' -H 'Sec-GPC: 1'
--data-raw 'requesttoken=BXxSJQVUJzsCOC8sHBYVeSMiGn1WGGEkElVLBxpqDSU%3D%3AS6jdaeSmCuHnvQvMwTQ14q6LHgrs%2F%2Bykkt79k1IzYlg%3D'
HTTP/1.1 303 See Other
Date: Thu, 14 Oct 2021 15:01:39 GMT
Server: Apache/2.4.41 (Ubuntu)
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Security-Policy: default-src 'none';manifest-src 'self';script-src 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src 'self';connect-src 'self';media-src 'self'
Location: http://localhost:45333?code=dgMwfBbS1X8rKqScYyZYcCdgqKIoRWRHnuKl0DmY09YFgA0ZpUG8isL0Pmg2DAPN&state=-NuSbdb3dZqX5fjUnSbRxo960Jqw7--Dhzc7rf06p94%3D
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Same steps as above, first connect with the phone's browser as admin, then connect with the app and switch user to 'User One' before authorize.
When the authorize button is pressed, An error appears onscreen "Legitimierung nicht erfolgreich"
The server log has owncloud-server-android-oauth51rc1.log.zip
Android logfile android.log.zip
10-14 22:57:14.157 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] Length: 69 byte body
10-14 22:57:14.169 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] Length: 69 byte body
10-14 22:57:14.181 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] Type: application/json; charset=utf-8
10-14 22:57:14.191 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] Type: application/json; charset=utf-8
10-14 22:57:14.202 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] --> Body start for response
10-14 22:57:14.212 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] --> Body start for response
10-14 22:57:14.225 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] {"error":"invalid_grant","error_description":"code verifier invalid"}
10-14 22:57:14.238 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] {"error":"invalid_grant","error_description":"code verifier invalid"}
10-14 22:57:14.249 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] <-- Body end for response -- Omitted: 0 bytes
10-14 22:57:14.260 D: (LogBuilder.kt:38) .logHttp()(10763): [Network, response] [body] [08455d8b-c366-4eb3-8108-5c21a4d7f3c9] <-- Body end for response -- Omitted: 0 bytes
10-14 22:57:14.270 E: (TokenRequestRemoteOperation.kt:77) .run()(10763): Failed response while getting tokens from the server status code: 400; response message: {"error":"invalid_grant","error_description":"code verifier invalid"}
10-14 22:57:14.276 E: (TokenRequestRemoteOperation.kt:77) .run()(10763): Failed response while getting tokens from the server status code: 400; response message: {"error":"invalid_grant","error_description":"code verifier invalid"}
10-14 22:57:14.284 D: (RemoteOperationResult.java:301) .<init>()(10763): RemoteOperationResult has processed UNHANDLED_HTTP_CODE: 400 Bad request
10-14 22:57:14.291 D: (RemoteOperationResult.java:301) .<init>()(10763): RemoteOperationResult has processed UNHANDLED_HTTP_CODE: 400 Bad request
10-14 22:57:14.304 E: (TokenRequestRemoteOperation.kt:82) .run()(10763): Exception while getting tokens
10-14 22:57:14.304 E: (TokenRequestRemoteOperation.kt:82) .run()(10763): java.lang.IllegalStateException: closed
Without switching user before authorization, the login succeeds.
The autorization code is tied to the user. Changing the user will result in a different code and the verifier no longer matches.
Smalls like works as designed .....
Smalls like works as designed .....
Then remove the "Switch users to continue" feature from the OAuth 2.0 app?
Then remove the "Switch users to continue" feature from the OAuth 2.0 app?
sounds reasonable ..... will think about this ...
Scenario: Client was connected with user1, But Browser meanwhile connected user2. Then the client gets disconnected, and wants to reconnect. The browser has the wrong (user2) cookie. Without switching, the client can never get connected again.
-> I vote against dropping the switch user feature.
Reproduced today again with oauth2 0.5.2 on 10.9.0-beta1 and user-ldap 0.16.0 rc2
@jvillafanez @DeepDiver1975 do you see a way to fix this? "Works as designed" might also indicate the design is lacking?
Scenario: Client was connected with user1, But Browser meanwhile connected user2. Then the client gets disconnected, and wants to reconnect. The browser has the wrong (user2) cookie. Without switching, the client can never get connected again.
After playing around with this scenario, the question I have is, what should happen with the browser afterwards?
I've hacked things a bit with mitmproxy in order to forward the code_challenge and the code_challenge_method to the POST request that happens when you click the "authorize" button (last step, after switching the user and just before the "code verifier invalid" error happens). It seems that the desktop client successfully login, but the browser ends up in the login page "https://test.server/login?redirect_url=%252Fapps%252Foauth2%252Fauthorization-successful"
Basically, you had a valid session with a user and that session is lost, so you're forced to log in again. Things might be worse if you end up using the "user2" account (the one you're logging in with the desktop client) instead of the account you had before initiating the desktop login process.
Maybe it's better to show a message to the user to force him to logout before initiating the desktop login. The flow would be something like:
This way is more clear to the user that he'll be logged out from ownCloud and that he'll eventually need to login again. After the user has logged out, the user will need to restart the flow from the desktop client (either login again or reopen the browser buttons should work)
The expected changes for this solution should be just change the "switch users" button for a "logout" button and some additional message to warn the user about the logout.
While debugging we would consistently see the code verifier invalid
response and ended up forwarding the code challenge from the authorization request to the logout request and again to the authorization request: https://github.com/owncloud/oauth2/pull/327/commits/3e4ea9cd149833bbffb0e81972e012112a626792
That did solve the issue when clicking 'switch user' and then using the same user to log in. It seems to me that change might affect this issue as well.
Seen with server 10.8.0 with oauth2-0.5.1-rc1 and user_ldap-0.15.4 and testpilotcloud-client 2.9.0-rc1
The server database has
Client logfile:
20211012_1038_owncloud.log.1.zip
On a second attempt, the client was logged in, although the server logs an error: