tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Basic authentication without a secure connection
Date Sun, 03 May 2009 18:53:11 GMT

just repeating some of the things you've said previously :

Tokajac wrote:
> I want to connect applications: one is running on Tomcat (Java/Struts) with
> another (php).
> I want to pass credentials after link is clicked, so I don't need to fill
> the username and password informations. I see that I might need to add row: 
> "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
> in the request header.
>>> I want to send credentials to the Authentication Dialog that's shown by
>>> application which is running on another server.
>>> With this idea, I'd connect 2 application: the Tomcat application should
>>> have a redirection link to the other application.
>>> If I can modify the request header, I will add row "Authorization: Basic
>>> QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
 > User should access the application directly (not proxying).
 > On
 > as I see header is created for programatic access and not via browser.

 > Is it possible to do this when I use browser for accessing? How?

Someone is missing something here (either you or us).

Either what you want to do does not make a lot of sense, or else we 
don't understand what you mean.
You say above :
"User should access the application directly (not proxying)."
Than why does the user not do it ? why do you have to put Tomcat and 
your Struts application in the middle ?

Schematically, there are different ways :

User (browser)  ---> Tomcat --> Struts application
User (browser)  ---> ?????? --> php application

In that case (1), you don't have to do anything.  The user just access 
your Tomcat application OR the php application.  If they access the php 
application, they have to login and that's it.

User --> Tomcat --> Struts application
          Tomcat --> other server/php application

In that case, what you are asking is for Tomcat to "proxy" the call to 
the php application, and make it look to the user as if this is a direct 
call to the php application.
In that case, Tomcat would just be the "mailbox" between the user and 
the php server.  It would just pass the entire user request to the php 
server, get the entire response, and pass evrything back to the user.
"everything" would include all the HTTP headers in both directions, 
including the authorization ones.  The user would still have to login.

But, there is not really any "standard" module in Tomcat to do that kind 
of proxying. See (4) below.

User --> Tomcat --> Struts application
          Tomcat --> special application --> calls php application

In that case, a special application in Tomcat makes the request to the 
php application.  Then it is that special Tomcat application that must 
do the authentication with the back-end server, and then you need some 
kind of HTTP client library in your Tomcat application (like Apache's 
HTTPClient library), to make your application "look like a browser" to 
the php application.
The only advantage of that solution, is if you want to get the php 
results inside your Tomcat application, transform them in some way, and 
send then back to the user in another format.
But it is quite complicated to do, and it is not just "copying the 
authorization headers".

User --> front-end --> Tomcat --> Struts application
          front-end --> other server --> php application

If you don't need to be in-between, that is the easiest solution.
As the front-end, you can use many things.  Apache httpd being only one 
of the possibilities.

So, which kind of scenario is yours ?
And if it is not 4, then why exactly do you want Tomcat and/or Struts to 
be in-between the user and the php application ?

Note (*) : that is maybe where you misunderstand something.
The "basic authentication dialog" which you see in the browser, does not 
come from the server.  It is an internal dialog from the browser.
The browser displays this dialog when it tries to access a page on the 
server, and the server sends back a "401 Authorization required" response.
Then the user types a user-id and password.
The the browser sends /the same request again/, but this time with an 
additional HTTP header :
Authorization: ..........
Then the server /verifies/ this user-id and password contained in that 
header, and if it is ok, it sends back the requested page.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message