Re: Considerations for the WebDAV servlet
Michael, On 10/1/24 12:14, Michael Osipov wrote: On 2024/10/01 15:20:53 Rémy Maucherat wrote: On Tue, Oct 1, 2024 at 4:53 PM Michael Osipov wrote: Folks, I'd like to put some effort into the DefaultServlet and the WebDAV servlet to align them more with mod_autoindex and add some minor improvements if I can cover my usecases here at work. Currently, I use mod_dav which I want to replace with the WebDAV servlet because I don't have the authz components in HTTPd like I have in Tomcat (it is rather a pain since I need to sync groups into a local file). The config in HTTPd is straight forward: ProxyPassMatch "!" AliasMatch "^/(backend-dev|content-dev|prod)/dav(/|$)(.*)" "/var/foo/$1$2$3" Dav On AuthType GSSAPI AuthName "Foo WebDAV Repository" AuthzSendForbiddenOnFailure On Options Indexes IndexOptions FancyIndexing FoldersFirst Charset=UTF-8 NameWidth=* SuppressDescription AuthGroupFile /var/foo/db/apache-groups.txt Require group foo-maintainers bar-maintainers baz-maintainers AddDefaultCharset utf-8 AddType text/plain .log .tex /(backend-dev|content-dev|prod) are proxied to three Tomcat instances, the config above would be replaced with subcontexts at /(backend-dev|content-dev|prod)#dav (solely for the DAV purpose) where the web.xml contains: webdav org.apache.catalina.servlets.WebdavServlet listings true showServerInfo false sortListings true sortDirectoriesFirst true fileEncoding UTF-8 1 webdav /* WebDAV /* Foo Maintainer Bar Maintainer Baz Maintainer and the context.xml (for backend-dev): It just works from the browser, CarotDAV, the Windows Explorer, and py-webdavclient3. Now my question/concern is the Javadoc of the servlet [1] says: The WebDAVServlet must not be used as the default servlet (ie mapped to '/') as it will not work in this configuration. Well, it works, doesn't it? And the sample below maps to root as well: webdav /* So what is it now, can I safely use the servlet with this setup? There is nothing else in this WAR file except context.xml, web.xml and a properties file. /* mapping is very different from /. / is the default servlet. /* is not and has a priority over it. The javadoc which you linked to has a mapping example of the WebDAV servlet using /*, which is 100% ok. Ahhh, you are right. It is a subtile difference. I want to evalute yet another option depicted in the DefaultServlet Javadoc, but in any case it looks good so far. IMHO It's worth pointing out in this same place in the documentation that "/ is bad but /* is okay". When I read your question I thought "/ != /*" but not every user would understand the distinction. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Considerations for the WebDAV servlet
On Wed, Oct 2, 2024 at 4:47 PM Christopher Schultz wrote: > > Michael, > > On 10/1/24 12:14, Michael Osipov wrote: > > On 2024/10/01 15:20:53 Rémy Maucherat wrote: > >> On Tue, Oct 1, 2024 at 4:53 PM Michael Osipov wrote: > >>> > >>> Folks, > >>> > >>> I'd like to put some effort into the DefaultServlet and the WebDAV servlet > >>> to align them more with mod_autoindex and add some minor improvements if I > >>> can cover my usecases here at work. > >>> > >>> Currently, I use mod_dav which I want to replace with the WebDAV servlet > >>> because I don't have the authz components in HTTPd like I have in Tomcat > >>> (it is rather a pain since I need to sync groups into a local file). > >>> > >>> The config in HTTPd is straight forward: > > ProxyPassMatch "!" > > > AliasMatch "^/(backend-dev|content-dev|prod)/dav(/|$)(.*)" > "/var/foo/$1$2$3" > > Dav On > AuthType GSSAPI > AuthName "Foo WebDAV Repository" > AuthzSendForbiddenOnFailure On > Options Indexes > IndexOptions FancyIndexing FoldersFirst Charset=UTF-8 NameWidth=* > SuppressDescription > > AuthGroupFile /var/foo/db/apache-groups.txt > Require group foo-maintainers bar-maintainers baz-maintainers > > AddDefaultCharset utf-8 > AddType text/plain .log .tex > > >>> > >>> /(backend-dev|content-dev|prod) are proxied to three Tomcat instances, the > >>> config above would be replaced with subcontexts at > >>> /(backend-dev|content-dev|prod)#dav > >>> (solely for the DAV purpose) where the web.xml contains: > > webdav > > org.apache.catalina.servlets.WebdavServlet > > listings > true > > > showServerInfo > false > > > sortListings > true > > > sortDirectoriesFirst > true > > > fileEncoding > UTF-8 > > 1 > > > > webdav > /* > > > > > WebDAV > /* > > > Foo Maintainer > Bar Maintainer > Baz Maintainer > > > >>> > >>> and the context.xml (for backend-dev): > > > className="org.apache.catalina.core.PropertiesRoleMappingListener" /> > > className="net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator" > loginEntryName="tomcat-accept" > sendAuthInfoResponseHeaders="true" /> > > className="net.sf.michaelo.tomcat.realm.PacDataActiveDirectoryRealm" > loginEntryName="tomcat-accept" /> > > > > className="org.apache.catalina.webresources.DirResourceSet" > webAppMount="/" /> > > > >>> > >>> It just works from the browser, CarotDAV, the Windows Explorer, and > >>> py-webdavclient3. > >>> > >>> Now my question/concern is the Javadoc of the servlet [1] says: > The WebDAVServlet must not be used as the default servlet (ie mapped to > '/') as it will not work in this configuration. > >>> > >>> Well, it works, doesn't it? And the sample below maps to root as well: > > webdav > /* > > >>> > >>> So what is it now, can I safely use the servlet with this setup? > >>> There is nothing else in this WAR file except context.xml, web.xml and > >>> a properties file. > >> > >> /* mapping is very different from /. / is the default servlet. /* is > >> not and has a priority over it. > >> The javadoc which you linked to has a mapping example of the WebDAV > >> servlet using /*, which is 100% ok. > > > > Ahhh, you are right. It is a subtile difference. I want to evalute yet > > another option depicted in the DefaultServlet Javadoc, but in any case it > > looks good so far. > > IMHO It's worth pointing out in this same place in the documentation > that "/ is bad but /* is okay". When I read your question I thought "/ > != /*" but not every user would understand the distinction. The javadoc of the WebDAV servlet is the only documentation there is, and it is correct and accurate. Default mapping of WebDAV does not make sense at all since all the other Servlets mappings take precedence over the / mapping. As a result, the file manipulations would fail as soon as anything else is mapped. It is now possible for a Servlet to detect its mappings. As a resu
Re: [OT] accessing manager app
Michael, On 10/1/24 15:27, Michael Osipov wrote: On 2024/10/01 17:12:55 Christopher Schultz wrote: Michael, On 10/1/24 12:13, Michael Osipov wrote: On 2024/10/01 13:56:22 Christopher Schultz wrote: Michael, On 10/1/24 05:21, Michael Osipov wrote: On 2024/09/30 17:21:30 Christopher Schultz wrote: Michael, On 9/30/24 11:41, Michael Osipov wrote: Chris, On 2024/09/30 14:33:53 Christopher Schultz wrote: Michael, On 9/28/24 13:34, Michael Osipov wrote: On 2024/09/27 15:14:15 Christopher Schultz wrote: Sebastian, On 9/27/24 11:04, Sebastian Trost wrote: Francesco, On 26.09.2024 16:12, Francesco Viscomi wrote: Hi all, I'm not able to understand why I cannot access to http://localhost:8080/manager/html I've configured the user in tomcat.users.xml: I'm using tomcat 9; and jdk17; I've also noted that in my personal pc when try to access manager/html a pop up ask me to login (in my personal pc it works right) While when I try to use it in the company pc it gives me 401 unauthorized; I do not know what I have to modify on chrome to get access in manager app, I also use in the company pc Zscaler, but I do not know what I have to change in it (eventually) in order to access the manager app. Your corporate browser probably has basic authentication disabled. Check this site: https://jigsaw.w3.org/HTTP/Basic If there is no basic authentication popup where you can enter username/ password then this is probably the case. See: https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest- version-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47 I've really had it with Microsoft deciding that HTTP Basic authentication is just not okay. They seem to have forgotten that TLS makes it secure. The reasoning is never to share a long term secret: your password. HTTP Digest also requires pre-shared passwords. There is a subtile difference: the password is never transferred over the wire and does not appear on the target server. While that may be true, it is irrelevant. The MD5(username:reaml:password) must be known to the server. That is as good as the password in terms of security. The realm name can never be changed without changing all passwords. The algorithm used can never be changed without changing all passwords. The overwhelming majority of web-based applications use pre-shared passwords with FORM-based authentication over TLS. There is zero reduction in security when compared to HTTP Digest. In both cases, hashes can be stored on the server-side which is of course a best-practice. I am aware of that, but Digest is dead, at least via SASL. Unfortunately RFC 7804 never gained traction in this regard. HTTP Digest is a nightmare, but they are forcing users onto it. The key is to use SPNEGO in enterprise environments. What about non-enterprise environments? IMHO, this is irrelevant for Microsoft. In enterprise you do have at least SPNEGO or even PKI. For non-enterprise I see only Basic as a viable option. Except that Microsoft is killing it. Yes, unfortunately. They never and will never care about non-AD users. At $work, we use WebDAV over TLS with an OpenLDAP back-end for authentication. It works great for all employees except those who use Windows. It seems like every installation of Windows needs a different hack to get HTTP Basic working when connecting to WebDAV. As said, all requires SPNEGO. WebDAV for Windows Explorer just works with SPNEGO and nothing else. You still can use a KDC like Samba to achieve the above without losing the LDAP bind-based authentication, but OpenLDAP will handle over to a KDC. I'd be interested to see some references for getting SPNEGO to work with httpd mod_dav and OpenLDAP as a back-end. If it can expose Kerberos to clients, I'll gladly give it a shot. Here you go: https://lists.apache.org/thread/dnmrcgq5f1txsf7shh3dq7m044bdkv4k> Now you need to use mod_authnz_ldap as authorization provider. I'm already using mod_authnz_ldap. AuthType GSSAPI looks like it requires a third-party module and, possibly, a Kerberos "implementation". It looks like my Debian-based system has a package "libapache2-mod-auth-gssapi" which has a dependency on "libgssapi-krb5-2". Is that essentially all I need? My bad, I should provided you https://github.com/gssapi/mod_auth_gssapi Fairly sure that's the source of the Debian package. Is there an equivalent of "AuthBasicProvider ldap" that I would need with gssapi to make it use the ldap provider? > As far as I understand https://httpd.apache.org/docs/2.4/mod/ mod_authnz_ldap.html#operation it not necessary because no Basic auth is performed. I would expect that REMOTE_USER is available to the module. I have tried, but documentation does not contradict. What I meant was, "how do I tell GSSAPI that I want it to use LDAP as the authentication back-end, as opposed to dbd, dbm, file, etc."? -chris
