Token-based WebDAV protocol is not working after upgrading 9.2.24 #7654
Assignees
Comments
|
Hi @geonmo, Thanks for sharing this issue. Could you also share your multimap configuration file? Cheers, |
|
@paulmillar Here it is. # /etc/dcache/multi-mapfile.wlcg_jwt
op:wlcg uid:1999 gid:1999,true username:wlcg_oidc
op:cms uid:50301 gid:1400,true username:cmsreadwrite
op:cmsv2 uid:50301 gid:1400,true username:cmsreadwriteNow that I think about it, I probably should have checked that the # symbol is a comment here. However, it worked fine in previous versions. |
|
Thanks @geonmo I think I understand the problem and have a fix. |
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
Sep 8, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: dCache#7654
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
Sep 8, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: dCache#7654
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
Sep 9, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: dCache#7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
Sep 9, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: dCache#7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
This was referenced Sep 9, 2024
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
Sep 9, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: dCache#7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
lemora
pushed a commit
that referenced
this issue
Sep 10, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: #7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
lemora
pushed a commit
that referenced
this issue
Sep 10, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: #7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
lemora
pushed a commit
that referenced
this issue
Sep 10, 2024
Motivation: Commit ef2dc1e introduced a regression in the multimap plugin. Where the 'op' principal type is used, logins will fail with dCache logging a stacktrace like: java.lang.RuntimeException: Failed to create principal: java.lang.NoSuchMethodException: org.dcache.auth.OAuthProviderPrincipal.<init>(java.lang.String) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildPrincipal(GplazmaMultiMapFile.java:148) at org.dcache.gplazma.plugins.GplazmaMultiMapFile$MappablePrincipal.buildMatcher(GplazmaMultiMapFile.java:163) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.asMatcher(GplazmaMultiMapFile.java:270) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.parseMapFile(GplazmaMultiMapFile.java:248) at org.dcache.gplazma.plugins.GplazmaMultiMapFile.mapping(GplazmaMultiMapFile.java:216) at org.dcache.gplazma.plugins.GplazmaMultiMapPlugin.map(GplazmaMultiMapPlugin.java:37) at org.dcache.gplazma.strategies.DefaultMappingStrategy.lambda$map$0(DefaultMappingStrategy.java:57) at org.dcache.gplazma.strategies.PAMStyleStrategy.callPlugins(PAMStyleStrategy.java:91) This problem is because the above commit replaced the single-string constructor that was being used by the multimap plugin via reflection. Modification: Define the following semantics: When `op` is used as a principal matcher, the matcher will be selected when the login has an OAuthProviderPrincipal with that value as its (dCache) name; for example, `op:FOO` will match if the login has an OAuthProviderPrincipal with name `FOO`. The URL of the issuer (the `iss` claim value) is not considered. This recreates the previous semantics. When used as a principal, the `op` takes two colon-sparated arguments: the (dCache) name for the OP and the issuer URL (the `iss` claim value). For example, `op:FOO:https://my-op.example.org/` creates an OP with name `FOO` and issuer URL `https://my-op.example.org/`. For backwards compatibility, if the second colon and the issuer URL is omitted then a placeholder URL is used and a warning is logged; for example, `op:FOO` will add a OAuthProviderPrincipal with name `FOO` and a placeholder issuer URL. Unit tests are added that verify correct behaviour. Result: A regression is fixed in the multimap plugin when `op:` principal type is used. Target: master Request: 10.1 Request: 10.0 Request: 9.2 Requires-notes: yes Requires-book: no Closes: #7654 Patch: https://rb.dcache.org/r/14314/ Acked-by: Tigran Mkrtchyan
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(I sent an email to dcache support saying the same thing, but thought I'd share this as a reference for others).
The following message appears, indicating that the token-based webdav protocol cannot be used.
If you've seen the same error after upgrading, please let us know in the comments, or if you haven't upgraded yet, you might want to wait a bit.
The text was updated successfully, but these errors were encountered: