Win a copy of Programming with Types this week in the Angular and TypeScript forum
or The Design of Web APIs in the Web Services forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Henry Wong
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Joe Ess
  • salvin francis

Error 401 Unauthorized When typing http://localhost:8080/manager/html (Alfresco Appl using Tomcat7)

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello

Setup: Alfresco application using tomcat 7.0.82 installed on Windows 2016 Server.

Problem: Error 401 Unauthorized - When typing   http://localhost:8080/manager/html
                      http://localhost:8080  works fine and returns the application main page.

* \tomcat\conf\tomcat-users.xml  file edited as follows:
 <?xml version="1.0" encoding="UTF-8"?>  
 <tomcat-users>
    <role rolename="manager-gui"/>
    <role rolename="manager-status"/>
    <role rolename="manager-jmx"/>
    <role rolename="manager-script"/>
    <user username="manager" roles="manager-gui, manager-status, manager-jmx, manager-script" password="whatever"/>
 </tomcat-users>

* \tomcat\conf\Catalina\localhost\manager.xml   file was created as follows:
 <?xml version="1.0" encoding="UTF-8"?>
 <Context antiResourceLocking="false" privileged="true" useHttpOnly="true" override="true">
 <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" securePagesWithPragma="false" />
 </Context >
 
* \tomcat\webapps\manager\META-INF\context.xml file as follows:
 <?xml version="1.0" encoding="UTF-8"?>
 <Context antiResourceLocking="false" privileged="true" >
   <Valve className="org.apache.catalina.valves.RemoteAddrValve"  allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" />
   <Manager sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
 </Context>

* Restarted the Tomcat7 Service

Question: What other files are involved in manager login process ?

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)

                 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 ?

Please advise.

Thanks
 
Saloon Keeper
Posts: 21437
143
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Isn't this the pre-installed Tomcat server mamager webapp? If so, have you modified it?

A "401" is what the webapp server normally sends back to a client to initiate a login, if my memory is accurate. In which case, my suspicion is that you didn't have the authentication type specified properly in the web.xml file. 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 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. One is to simply include the userid/password in the request URL (I believe it looks like this: https://fred@secret:localhost:8080/manager"). 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. However, I forget the details, and it's not the day for me to look things up.
 
Mike Morgan
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim

Thank you, sure it wasn't the right day to post questions Leave it after vacation.
Just to answer your questions:

Isn't this the pre-installed Tomcat server mamager webapp? If so, have you modified it?
 >> Yes I added the lines as requested into these files.

A "401" is what the webapp server normally sends back to a client to initiate a login, if my memory is accurate. In which case, my suspicion is that you didn't have the authentication type specified properly in the web.xml file. 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.
 >> I didn't touch yet the web.xml file but I receive a popup window to enter manager credentials

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. One is to simply include the userid/password in the request URL (I believe it looks like this: https://fred@secret:localhost:8080/manager"). 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. However, I forget the details, and it's not the day for me to look things up.
>> No, as mentioned, just an http URL

Merry Christmas
 
Tim Holloway
Saloon Keeper
Posts: 21437
143
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure about the need to add all those Valves. For the most part, the Manager webapp should run out of the box. Restricting the access to localhost isn't a bad idea, though.

There are two things I note.

First, the manager /META-INF/context.xml resource gets overridden by the catalina/localhost/manager.xml. And I'm pretty sure it's an all-or-nothing override, so you'd lose any options not repeated in manager.xml.

Secondly, for container-based login to work, you have to specify a Realm. In Tomcat, a Realm can be defined in the Context or in server.xml. Unless you're setting the same Realm for all webapps, usually you'd do in in the Context, and you haven't.

A Realm definition indicates which of the many Realm plug-in modules a particular webapp will use for authentication and authorization. The JDBCRealm, for example, uses JDBC to confirm user credentials and roles based on information in database tables. The LDAPRealm likewise does JDNI lookups. 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).

That may be your problem right there. 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. And for essentially every browser since primordial times, that should have been done automatically.
 
Mike Morgan
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please see my replies after the >> sign:

Note: I've re-formatted this to make it more readable - Tim

Tim Holloway wrote:
There are two things I note.

First, the manager /META-INF/context.xml resource gets overridden by the catalina/localhost/manager.xml. And I'm pretty sure it's an all-or-nothing override, so you'd lose any options not repeated in manager.xml.




>>  \Catalina\localhostmanager.xml file is as below in both Production (where I face 401) and in Lab (Ok):


>> manager /META-INF/context.xml (I put back the original, no localhost restriction)
 
-->


>> Note: The production setup is used in Domain Group policy .. while Lab setup in WORGROUP

Tim Holloway wrote:
Secondly, for container-based login to work, you have to specify a Realm. In Tomcat, a Realm can be defined in the Context or in server.xml. Unless you're setting the same Realm for all webapps, usually you'd do in in the Context, and you haven't.



>> tomcat\conf\context.xml  are left by default in both Production and Lab
>> Everything option inside is left commented.

You still haven't defined a security Realm. Actually, what you have defined is mostly just weird. 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.
I've never had the need to explicitly provide a Manager element at all - the default one works most of the time. Likewise, the Valve in your hostmanager.xml file is something that I have never had need to use.

What I do use, however, is a Realm definition. Like this one:


Here I'm actually using the same database for both the application data and the Realm authentication credential data. Not required, but sometimes convenient. A more paranoid system would use 2 different databases.

>> Question: is there a way to track/debug step by step the Authentication handshake failure ? Logs do not say enough details about the reason !

You can't track authentication if you don't have a Realm to Authenticate to. That's the primary reason why the logs don't help.

Actually, if you need to track authentication for a Realm, each Realm has its own logging channel, so you'd have to check the Realm's source code to see what the channel name and options were. But in general, they Just Work, so about the only time I've ever had to log a Realm is when it was a custom Realm I'd coded myself.
 
They weren't very bright, but they were very, very big. Ad contrast:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!