![]() You can't track authentication if you don't have a Realm to Authenticate to. > Question: is there a way to track/debug step by step the Authentication handshake failure ? Logs do not say enough details about the reason ! A more paranoid system would use 2 different databases. Here I'm actually using the same database for both the application data and the Realm authentication credential data. What I do use, however, is a Realm definition. Likewise, the Valve in your hostmanager.xml file is something that I have never had need to use. I've never had the need to explicitly provide a Manager element at all - the default one works most of the time. Your context.xml file provides a Manager definition that is overly-picky and would be something that you should only be using in a very unique clustered environment. Actually, what you have defined is mostly just weird. You still haven't defined a security Realm. > Everything option inside is left commented. > tomcat\conf\context.xml are left by default in both Production and Lab ![]() > Note: The production setup is used in Domain Group policy. > manager /META-INF/context.xml (I put back the original, no localhost restriction) > \Catalina\localhostmanager.xml file is as below in both Production (where I face 401) and in Lab (Ok): Note: I've re-formatted this to make it more readable - Tim And for essentially every browser since primordial times, that should have been done automatically. However, when presented with a "401", a web client should normally make an authentication request, and it sounds like your client isn't doing that. If you want to use the tomcat-users.xml file, you need MemoryRealm or one of its newer extended versions, MemoryRealm requires a restart of Tomcat to pick up changes to the tomcat-users.xml file - there's a newer Realm that can do that dynamically, but I forget its name (see the model server.xml file). The LDAPRealm likewise does JDNI lookups. The JDBCRealm, for example, uses JDBC to confirm user credentials and roles based on information in database tables. Unless you're setting the same Realm for all webapps, usually you'd do in in the Context, and you haven't.Ī Realm definition indicates which of the many Realm plug-in modules a particular webapp will use for authentication and authorization. In Tomcat, a Realm can be defined in the Context or in server.xml. Secondly, for container-based login to work, you have to specify a Realm. And I'm pretty sure it's an all-or-nothing override, so you'd lose any options not repeated in manager.xml. Restricting the access to localhost isn't a bad idea, though.įirst, the manager /META-INF/context.xml resource gets overridden by the catalina/localhost/manager.xml. ![]() For the most part, the Manager webapp should run out of the box. I'm not sure about the need to add all those Valves. > I didn't touch yet the web.xml file but I receive a popup window to enter manager credentials > Yes I added the lines as requested into these files. Thank you, sure it wasn't the right day to post questions Leave it after vacation. However, I forget the details, and it's not the day for me to look things up. One is to simply include the userid/password in the request URL (I believe it looks like this: My memory is fuzzier on the alternatives, but I believe that a client receiving a "401" can also interpret that as a request to send credentials (using client-written code) on demand. In the event that you're attempting to access a web service via a non-browser client app, and therefore have no dialog or form-reply mechanism in your client, alternative authentication schemes may be used. The two common options are "basic" and "form", depending on whether you want a pop-up dialog in the user's browser or a form display. In which case, my suspicion is that you didn't have the authentication type specified properly in the web.xml file. Isn't this the pre-installed Tomcat server mamager webapp? If so, have you modified it?Ī "401" is what the webapp server normally sends back to a client to initiate a login, if my memory is accurate. Shall I consider/look at the Folders/files permissions of the tomcat production server running the Alfresco application which may have tweaked file permissions for security reasons ? Note: I installed the same tomcat version on a Lab VM (Win 2016) and made the above changes/additions and it just worked fine (all the rest is kept as default) Question: What other files are involved in manager login process ? * \tomcat\webapps\manager\META-INF\context.xml file as follows: * \tomcat\conf\Catalina\localhost\manager.xml file was created as follows: * \tomcat\conf\tomcat-users.xml file edited as follows: Problem: Error 401 Unauthorized - When typing works fine and returns the application main page. Setup: Alfresco application using tomcat 7.0.82 installed on Windows 2016 Server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |