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 interface, something like
diff --git
a/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
b/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
index 776e613..fa32b59 100644
--- a/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
+++ b/src/main/java/org/apache/sling/api/SlingHttpServletRequest.java
@@ -18,6 +18,7 @@
*/
package org.apache.sling.api;
+import java.security.Principal;
import java.util.Enumeration;
import java.util.List;
import java.util.Locale;
@@ -274,4 +275,18 @@ public interface SlingHttpServletRequest extends
HttpServletRequest, Adaptable {
* @return The request progress tracker.
*/
@NotNull RequestProgressTracker getRequestProgressTracker();
+
+ /**
+ * Returns a <code>java.security.Principal</code> object
containing
+ * the name of the current authenticated user.
+ *
+ * <p><strong>Note: </strong> This method deviates from the parent
interface and never returns <code>null</code>,
+ * even whenthe user is not authenticated.</p>
+ *
+ * @return a <code>java.security.Principal</code>
containing
+ * the name of the user making this request;
never
+ * <code>null</code>
+ */
+ @NotNull
+ Principal getUserPrincipal();
}
>
> Regards
> Carsten
>
> On 20.07.2023 13:06, Jörg Hoh wrote:
> > 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 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 the non spec compliant
> > > behaviour
> > > is in there for many many years. There is a chance that some of
> > > our
> > > users rely on this behaviour. If we change it, we break our
> > > users. Which
> > > actually happened in this case.
> > >
> > > In addition, in this case if users are trying out our non spec
> > > compliant
> > > method they will immediately see that it is not compliant during
> > > development/testing.
> > >
> > > Regards
> > > Carsten
> > >
> > > On 20.07.2023 12:28, Konrad Windszus wrote:
> > > > 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 more:
> > > > 1) Spec compliance to make it easier for most new/existing
> > > > users as
> > > otherwise behaviour differs from Javadoc and underlying Spec.
> > > > 2) Backwards compatibility for those users who rely on this
> > > > spec
> > > incompatibility.
> > > >
> > > >
> > > > In my opinion I would clearly go for 1) but I would like to
> > > > hear other
> > > opinions.
> > > >
> > > > Thanks,
> > > > Konrad
> > >
> > > --
> > > Carsten Ziegeler
> > > Adobe
> > > cziege...@apache.org
> > >
> >
> >
>
