On 24 June 2016 at 10:01, Mark Thomas <ma...@apache.org> wrote: > On 24/06/2016 06:30, Lyallex wrote: > > <snip/> > >> I think the current solution to 59399 need rethinking >> >> My commercial site has been up for years, there are links dating back >> years that refer to the old http scheme >> I have no control over this, now, whenever I get a hit from an 'old' >> link I need to force the switch to https, lots of sites have this >> probem and need a solution, it has nothing whatsoever to do with >> dabases in any way shape or form. >> >> So, >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399 >> >> What has the status code returned when switching from http -> https >> got to do with a Realm? > > It is the Realm that enforces the security constraints defined in > web.xml. This includes both authorisation constraints and user data > constraints. Forcing the use of TLS is a user data constraint. Hence the > ability to configure the redirect was added to the Realm implementations. > > <snip/> > >> Which Realm(s)? only JDBCDatabaseRealm has the attribute but your >> comment seems to imply that all Realms >> have it (transportGuaranteeRedirectStatus) > > It is supported for any Realm that extends org.apache.catalina.RealmBase > which is all the Realms that ship with Tomcat and, I should think, a > reasonable proportion of the custom Realm implementations as well. > > That it was only documented for one Realm was an oversight that I'll > correct shortly. (Along with the typo in the text.) > > <snip/> > >> In the 'good old days' it was common practice to only switch to https >> during or after signing in to an application, networks were slow and >> encryption takes time, now networks are faster and the overhead isn't >> such an issue. Entire sites now use the https scheme, I know mine >> does. I can see a situation where, because the mighty Google says it >> must be so, even an entirely static site with no database and no >> manager will be served up under https. How is such a site suppose to >> implement https? > > I assume the question here is how to configure the redirect status to > use when a web application does not configure a Realm. > > Whether an application configures a Realm or not, it will have one. If a > web application does not have a specific Realm configured Tomcat looks > at the Host and then the Engine. If a Realm is not configured for either > of these then the Engine will be configured with the NullRealm. > > Much like the way Tomcat automatically adds an Authenticator when > required but the user has to add it explicitly if they want to change > the default configuration for that Authenticator, the user has to > explicitly add the NullRealm and configure it if they want to change the > redirect status when no other Realm is defined. > > The NullRealm is currently undocumented. I'll fix that as well. > >> FYI I have it in black and white, from a Google webaster forum >> responder that, in the event of a tie between two pages in a ranking >> calculation, the https scheme would produce a ranking signal that >> would elevate the https page above the non https page in the resulting >> rankings. >> >> Once again this is not intended as criticsm of a dedicated and >> prolific committer > > You stated you think the current solution needs rethinking. You haven't > proposed an alternative and explained why the alternative is better.
Because I don't presume to have the knowledge of the Tomcat source code required to make such a statement. I do have explicit knowledge of a problem that I experienced while using open source software that you (and others) have written. I didn't understand the solution due to (apparently) incomplete documentation. What *exactly* is one supposed to do in this situation. I may not have the time to contribute source code but it took me a while to figure out exactly was going on and write a bug report, I consider this contributing to the project, maybe you don't. As it happens I did have a possible solution that maintained your abstraction (Realm) even though the connection between realm and redirect is *in my opinion* not intuitive and somewhat opaque and that was to add the required functionality to the Realm base class (if such an entity exists). Then, by way of an attribute expose that functionality in your chosen Realm. This sounds remarkably like the solution you have come up with ... However I can't get my head around your assertion that forcing the use of TLS is a 'user data constraint' but it appears that any attempted discussion of design decisions is considered a criticism at least and a personal insult at worst so I won't go there. Thank you for your explanation and I eagerly await the updated documentation. Lyallex > > Mark > > > --------------------------------------------------------------------- > 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
