On Wed, Nov 16, 2022 at 1:36 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Thorsten,
>
> On 11/16/22 03:20, Thorsten Schöning wrote:
> > Guten Tag Christopher Schultz,
> > am Mittwoch, 16. November 2022 um 04:50 schrieben Sie:
> >
> >> <Realm className="org.apache.catalina.realm.UserDatabaseRealm" 
> >> resourceName="UserDatabase">
> >> <CredentialHandler
> >> className="org.apache.catalina.realm.SecretKeyCredentialHandler"
> >>                           algorithm="PBKDF2WithHmacSHA512"
> >>                           iterations="100000"
> >>                           keyLength="256"
> >>                           saltLength="16"
> >> </Realm>
> >
> > That worked right from the start, I had a DIGEST in tomcat-users.xml
> > and was able to login with plain-text password provided to the
> > browser.
>
> The use of the word "digest" is overloaded, particularly for this
> discussion. Please try to use "HTTP DIGEST" when you mean the
> on-the-wire authentication protocol and "hashed credential" when you
> mean the stuff you drop into an authentication database. It will make
> things a lot easier to understand for all parties involved.
>
> >> <Realm  className="org.apache.catalina.realm.LockOutRealm">
> >> ...
> >> </Realm>
> >
> > Adding that didn't work, I was only able to login with providing the
> > DIGEST of tomcat-users.xml as password to the browser, which actually
> > made it a plain-text password at the server. The following fit as well
> > to what I recognized:
> >
> > https://stackoverflow.com/questions/64733766/how-to-get-tomcat-credentialhandler-inside-java-when-nested-in-lockoutrealm
> >
> > BUT: I gave things an additional try now and especially after the
> > discussion about auth-method BASIC vs. DIGEST and login DOES work now!
>
> So both the UserDatabase realm and the LockOutRealm as I suggested above
> are now working as expected?
>
> > I most likely not only added LockOutRealm at some point, but switched
> > from BASIC auth to DIGEST as well, because I've read that in the CIS
> > spec I worked with. That combination can't work and at some point I
> > most likely became frustrated and changed DIGEST back to BASIC, while
> > having changed other aspects of the realms already or might have
> > simply forgotten to change passwords vs. digests in tomcat-users.xml
> > or whatever.
> >
> > So, I guess the reason for the warnign about an ignored credential
> > helper in LockOutRealm simply is because it doesn't handle credentials
> > at all? And as LockOutRealm forwards actual login to its children
> > THEIR assigned credential handlers are properly taken into account?
>
> Yes, no CombinedRealm ever uses its configured CredentialHandler, which
> is why the warning is shown.
>
> There is a very specific case in which you WANT to configure a
> CredentialHandler for a CombinedRealm, and that's when your application
> is using the CredentialHandler directy for certain things. That doesn't
> seem to be your use-case, so I won't detail that, here. If you re-visit
> the SO question you posted yesterday, you'll see that I posted an Answer
> which describes that a little more.
>
> > So whatever the SO-guy sees, might have a different root cause, as it
> > was the case for me.
> >
> > Thanks for triggering me to try again! Might have been to late already
> > at Monday as well. :-)
>
> I'm glad it's working.
>
> After reading Rémy's initial response, I was thinking that something
> needed to be done, but there is no problem IMO. If you need a
> CredentialHandler in your application, you can still use LockOutRealm
> (or any other CombinedRealm); you just have to specify a
> CredentialHandler to use on that outer Realm and all is well.
>
> And you have to ignore that warning.

Sure, but I plan to try something a little better because why not.

Rémy

> I really don't know why you are seeing that warning. You aren't
> explicitly-setting a CredentialHandler on your LockOutRealm and that's
> the only time this warning should be shown. When
> CombinedRealm.startInternal runs, it creates a trivial CredentialHandler
> (I'm not sure why it does that, actually) but only if the reference is
> null and then it sets the class member directly instead of calling
> setCredentialHandler.
>
> So I'm still a little confused as to why you are seeing what you are seeing.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to