[
https://issues.apache.org/jira/browse/SLING-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962562#comment-15962562
]
Julian Sedding edited comment on SLING-6772 at 4/10/17 8:28 AM:
----------------------------------------------------------------
I'm fine with your suggestion (don't fully understand the property name, yet,
but that's not critical imho).
-Could we additionally enhance the javadoc to mention that "subservice name"
should (must?) not have a double dash? We could even enforce it via an illegal
argument exception. That way we could check for the last occurrence of a double
dash to identify the "subservice name". As it is optional, we would als need to
fall back to interpreting everything after {{serviceuser\-\-}} as the BSN. At
the very least we need to document this constraint on "subservice name" for the
default user mapping.-
-We could always log a warning or error (or even throw an exception) if there
is ambiguity and help the developer fix it by changing the subservice name or
by providing an explicit configuration.-
EDIT: After looking at the code, I think the above does not apply, since the
user-name is generated, but does not need to be parsed. Therefore, either we
find a user with a matching principal name, or we have no effective mapping (in
which case I hope there is a warning/error, probably a LoginException).
was (Author: jsedding):
I'm fine with your suggestion (don't fully understand the property name, yet,
but that's not critical imho).
-Could we additionally enhance the javadoc to mention that "subservice name"
should (must?) not have a double dash? We could even enforce it via an illegal
argument exception. That way we could check for the last occurrence of a double
dash to identify the "subservice name". As it is optional, we would als need to
fall back to interpreting everything after {{serviceuser\-\-}} as the BSN. At
the very least we need to document this constraint on "subservice name" for the
default user mapping.-
-We could always log a warning or error (or even throw an exception) if there
is ambiguity and help the developer fix it by changing the subservice name or
by providing an explicit configuration.-
After looking at the code, I think the above does not apply, since the
user-name is generated, but does not need to be parsed. Therefore, either we
find a user with a matching principal name, or we have no effective mapping (in
which case I hope there is a warning/error, probably a LoginException).
> Provide default mapping for service users
> -----------------------------------------
>
> Key: SLING-6772
> URL: https://issues.apache.org/jira/browse/SLING-6772
> Project: Sling
> Issue Type: Improvement
> Components: Service User Mapper
> Reporter: Carsten Ziegeler
> Assignee: Carsten Ziegeler
> Fix For: Service User Mapper 1.3.0
>
> Attachments: SLING-6772.karaf.patch, SLING-6772.repoinit.patch
>
>
> As discussed in [1] we should aim at making Sling configurationless again.
> One part which currently always needs configurations is the service user
> mapper. We should add a default mapping, from a bundle symblic name and sub
> service to
> {noformat}
> "serviceuser@" + {bundle.symblicName} + [":" + sub service]
> {noformat}
> [1]
> https://lists.apache.org/thread.html/6f90d751ddd20d7041475ba5d5fc89beda1906048ff91cc2f564e63e@%3Cdev.sling.apache.org%3E
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
