Re: Considerations for the WebDAV servlet
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. > > Michael > > > > [1] > > https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/servlets/WebdavServlet.html > > > > - > > 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 > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] accessing manager app
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. The Kerberos principal needs to be mapped to an LDAP attribute, dependening on the system it could be userPrincipal or krb5Principal. Give it a shot, if you have the setup. On Tomcat side I have replaced LDAP authz with something much better/faster for most of the use cases. M - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: [OT] accessing manager app
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? Is there an equivalent of "AuthBasicProvider ldap" that I would need with gssapi to make it use the ldap provider? The Kerberos principal needs to be mapped to an LDAP attribute, dependening on the system it could be userPrincipal or krb5Principal. Give it a shot, if you have the setup. I'll see what I can do. Thanks for the pointer. On Tomcat side I have replaced LDAP authz with something much better/ faster for most of the use cases. There is no Tomcat in this particular environment. Just httpd and a disk. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] accessing manager app
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. > There is no "Enterprise" here. There are no Domain Controllers here. > There is no expensive third-party authentication-as-a-service company > here. There is only a standards-compliant service which is not reliably > accessible to users on Microsoft Windows. ...there is no need, as said you can use Samba as a decent identity provider or MIT Kerberos paired with an OpenLDAP backend. Both do work, both are open source. No IaaS required. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using HTTP 1.1 over a configured HTTP2 Connector
On 01/10/2024 06:15, Anurag Sharma wrote: Dear Tomcat Team, I hope this message finds you well. I am currently facing a challenge regarding the use of HTTP/1.1 for specific API endpoints within a servlet configured for HTTP/2. My browser defaults to HTTP/2, which complicates the situation as I need to proxy some APIs to a server that only supports HTTP/1.1. Is there a workaround available to enforce HTTP/1.1 for these particular endpoints? It isn't clear from the above which component needs to talk to which using what protocol. Servlets don't care whether the request is received via HTTP/1.1 or HTTP/2. Tomcat will happily process requests for the same servlet using HTTP/1.1 or HTTP/2 depending on client support. Outgoing requests from Tomcat to external services are outside of the control of Tomcat and are entirely an application concern. Can you be more precise about what the problem is? Mark Here is out server.xml config. All request from our app is http2 protocol. Thank you so much for your help. Thanks and Regards, Anurag Sharma - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using HTTP 1.1 over a configured HTTP2 Connector
Mark and Anurag, On 10/1/24 08:38, Mark Thomas wrote: On 01/10/2024 06:15, Anurag Sharma wrote: Dear Tomcat Team, I hope this message finds you well. I am currently facing a challenge regarding the use of HTTP/1.1 for specific API endpoints within a servlet configured for HTTP/2. My browser defaults to HTTP/2, which complicates the situation as I need to proxy some APIs to a server that only supports HTTP/1.1. Is there a workaround available to enforce HTTP/1.1 for these particular endpoints? It isn't clear from the above which component needs to talk to which using what protocol. Servlets don't care whether the request is received via HTTP/1.1 or HTTP/2. Tomcat will happily process requests for the same servlet using HTTP/1.1 or HTTP/2 depending on client support. Outgoing requests from Tomcat to external services are outside of the control of Tomcat and are entirely an application concern. Can you be more precise about what the problem is? Also... where is the proxy? Out in front of Tomcat, or is your application acting as the proxy? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] accessing manager app
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. There is no "Enterprise" here. There are no Domain Controllers here. There is no expensive third-party authentication-as-a-service company here. There is only a standards-compliant service which is not reliably accessible to users on Microsoft Windows. ...there is no need, as said you can use Samba as a decent identity provider or MIT Kerberos paired with an OpenLDAP backend. Both do work, both are open source. No IaaS required. I don't intend to introduce Samba as a component if I can help it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Considerations for the WebDAV servlet
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. Michael [1] https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/servlets/WebdavServlet.html - 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 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. Rémy > Michael > > [1] > https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/servlets/WebdavServlet.html > > - > 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
Re: [OT] accessing manager app
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
