Service authentication with principals-only (and without system user)
Hi all, since quite a while it's possible to configure principals instead of a user for service authentication [1]. IMHO this suggests that an actual authorizable should not be required anymore, but testing it showed that this is explicitly checked and forbidden [2]. Now looking at how the code hooks into oak [3], at least on Sling side there seems little reason for this requirement. On oak side there are obvious places where "some user id" is needed [4] but maybe this could be auto-generated? Could somebody clarify why a backing service user is needed and if (maybe :)) it would be possible to work towards getting rid of this requirement? -Georg [1] https://issues.apache.org/jira/browse/SLING-6963 https://sling.apache.org/documentation/the-sling-engine/service-authentication.html#service-user-mappings [2] https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/541c918ef0869c9ff88b86ab96235ef07740c643/src/main/java/org/apache/sling/jcr/resource/internal/JcrSystemUserValidator.java#L219 [3] https://github.com/apache/sling-org-apache-sling-jcr-base/blob/e8fe5e004b5af1802bb2a76dbbb583a437f848ee/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepository2.java#L242 [4] https://docs.adobe.com/docs/en/spec/javax.jcr/javadocs/jcr-2.0/javax/jcr/Session.html#getUserID()
[jira] [Commented] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981178#comment-16981178
]
Evgeny Tugarev commented on SLING-8706:
---
[~joerghoh] I made a progress with the implementation, please have a
look/comment.
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [sling-org-apache-sling-models-impl] etugarev commented on issue #17: SLING-8706 - Injections for java.util.Optional<> should be automatically optional
etugarev commented on issue #17: SLING-8706 - Injections for java.util.Optional<> should be automatically optional URL: https://github.com/apache/sling-org-apache-sling-models-impl/pull/17#issuecomment-557924828 I improved test coverage and tested also on sandbox project, to make sure all the injector-specific annotations are working as before (`@ChildResource`, `@RequestAttribute`, `@ScriptVariable` etc). No problems so far. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[VOTE] Release Apache Sling Scripting Core 2.1.0, Apache Sling Servlets Resolver 2.5.8, Apache Sling Resource Resolver 1.6.16
Hi, We solved 4 issues in these releases: https://issues.apache.org/jira/browse/SLING/fixforversion/12346257 https://issues.apache.org/jira/browse/SLING/fixforversion/12346536 https://issues.apache.org/jira/browse/SLING/fixforversion/12346273 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2160/ You can use this UNIX script to download the release and verify the signatures: https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD Usage: sh check_staged_release.sh 2160 /tmp/sling-staging Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This majority vote is open for at least 72 hours. Regards, Radu Cotescu
[jira] [Updated] (SLING-8695) Make sure that the Sling modules' pom files provide a name value that's consistent with the JIRA releases
[
https://issues.apache.org/jira/browse/SLING-8695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radu Cotescu updated SLING-8695:
Summary: Make sure that the Sling modules' pom files provide a name value
that's consistent with the JIRA releases (was: Make sure that the Sling
modules' pom files provide name value that's consistent with the JIRA releases)
> Make sure that the Sling modules' pom files provide a name value that's
> consistent with the JIRA releases
> -
>
> Key: SLING-8695
> URL: https://issues.apache.org/jira/browse/SLING-8695
> Project: Sling
> Issue Type: Task
>Reporter: Radu Cotescu
>Priority: Major
>
> In order to easier map a Sling module to a JIRA release we should make sure
> that the value provided in the pom in the {{}} tag corresponds to the
> JIRA release naming scheme.
> Current status (taking Apache Sling Scripting Core as an example):
> {code:java|title=Apache Sling Scripting Core pom.xml}
> org.apache.sling.scripting.core
> 2.0.59-SNAPSHOT
> Apache Sling Scripting Core implementation
>
> Sling Scripting core functionality
>
> {code}
> JIRA:
> [https://issues.apache.org/jira/projects/SLING/versions/12345580] -
> "Scripting Core 2.0.60"
> Ideally the mapping should be something like:
> {code:java|title=Apache Sling Module Name pom.xml}
> org.apache.sling.artifactId
> 0.0.1-SNAPSHOT
> Apache Sling Module Name
>
> ...
>
> {code}
> whereas the JIRA version name corresponding to the module should be "Module
> Name 0.0.1-SNAPSHOT".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
