I added the switch.
If anyone wants improvements to this, please directly commit or PR
Thanks
Carsten
On 21.07.2023 06:32, Carsten Ziegeler wrote:
Sure, we can make this configurable. Nevertheless, I strongly suggest
everyone to not rely on this method returning null for the anonymous
case
Sure, we can make this configurable. Nevertheless, I strongly suggest
everyone to not rely on this method returning null for the anonymous
case and rather use the other two methods - which always behaved spec
compliant. Otherwise you might run into trouble once you combine two
sources of code
Carsten, unfortunately, it seems that the problem is more complicated than
how you have described it. There have been 2 public releases of
org.apache.sling.engine with the fix from SLING-11825 included. People
(including me) have already migrated to those releases and made changes to
their code
Good point, I updated them
https://github.com/apache/sling-org-apache-sling-api/commit/b76ab7e07c79dab4cd89eb25784848c2f5ad2732
Regards
Carsten
On 20.07.2023 15:22, Robert Munteanu wrote:
+/**
+ * Returns a java.security.Principal object
containing
+ * the name of the current
On Thu, 2023-07-20 at 14:34 +0200, Carsten Ziegeler wrote:
> Sure, the question is where?
>
> I looked at our existing docs, and we actually document how to check
> for
> anonymous access. But that is a little bit hidden, embedded in
> outdated
> docs
We can start with the javadoc of the
Hi,
yes I'm heavily opting for 2) :) you know I initially approved your PR
thinking that this should not break any of Sling's users.
Well, today I know that this assumption was wrong. I know of several
users which currently rely on the wrong behaviour - and changing it
breaks them.
The
> On 20. Jul 2023, at 12:53, Carsten Ziegeler wrote:
>
> I think there is no one solution fits all here. As always it depends.
Yes, I agree with that. I was referring to this specific use case.
>
> In general we should try to be spec compliant - unless there is a good reason
> not to. There
Sure, the question is where?
I looked at our existing docs, and we actually document how to check for
anonymous access. But that is a little bit hidden, embedded in outdated
docs
Regards
Carsten
On 20.07.2023 13:06, Jörg Hoh wrote:
Should we document that in this case we are not spec
Should we document that in this case we are not spec compliant for
backwards compatibility reasons?
Am Do., 20. Juli 2023 um 12:53 Uhr schrieb Carsten Ziegeler <
cziege...@apache.org>:
> I think there is no one solution fits all here. As always it depends.
>
> In general we should try to be spec
I think there is no one solution fits all here. As always it depends.
In general we should try to be spec compliant - unless there is a good
reason not to. There could be different reasons.
In this particular case, imho there is a good reason to not be
compliant. We have a huge user base and
Hi,
Carsten just reverted the fix from
https://issues.apache.org/jira/browse/SLING-11825 in
https://issues.apache.org/jira/browse/SLING-11974.
The fix is correct according to the Servlet Spec, but it seems some customer
rely on Sling behaving not spec compliant here.
The question is what weighs
11 matches
Mail list logo
