anunnakian / openid4java

Automatically exported from code.google.com/p/openid4java
Apache License 2.0
0 stars 0 forks source link

Return_To URL verification failed on default port 80 #105

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I have a case where the method

public boolean verifyReturnTo(String receivingUrl, AuthSuccess response)

from the ConsumerManager failed while the receivingUrl String did not
contain a Portnumber but the AuthSuccess response.getReturnTo() did.
For example my receivingUrl is "http://www.mydomain.com/xxx"
and my ReturnTo URL - generated in the authenticate process before in the
livecycle - contains the default port 80 "http://www.mydomain.com:80/xxx"

I am not sure, but I think I have this issue in my productive glassfish
environment because of a virtual Host configuration. 

So as a result of this situation the method 
  verifyReturnTo(String receivingUrl, AuthSuccess response)

inside the ConsumerManager faild because the compare of 
receiving.getAuthority().equals(returnTo.getAuthority() 
is now not(!) equal.

My proposal to solve this situation is to check if the two URL objects have
a port number provided.
In the case of "http://www.mydomain.com/xxx" the method getPort() will
return -1. 
So a check of this situation will solve the problem in the following equals
compare.
We can fix this with the following additional code snippet:

   if (receiving.getPort()==-1)
    try {
    // create new URL object with default port 80
    receiving = new
URL(receiving.getProtocol(),receiving.getHost(),80,receiving.getFile());
    } catch (MalformedURLException e) {
        e.printStackTrace();
    }

What do you think about this change?
Currently I am solving the problem in my login module where I check the
receiverURl before I call the Method consumerManger.verify(....)

Please see also my posting:
http://groups.google.com/group/openid4java/browse_thread/thread/d925d7b04abc1bf6

It could be necessary to check also the returnTo URL object....

Original issue reported on code.google.com by Ralph.so...@imixs.com on 18 Jan 2010 at 11:05

GoogleCodeExporter commented 9 years ago
The consumer should call ConsumerManager.authenticate() with the URL where it 
expects to receive the responses. The OpenID Provider will copy its exact 
string 
value into the authentication response.

Adding extra logic is unnecessary in this case and can potentially add bugs; 
for 
example, it is incorrect to default to port 80 without checking the protocol 
being 
used.

Original comment by Johnny.B...@gmail.com on 24 Mar 2010 at 1:57

GoogleCodeExporter commented 9 years ago
Hi,
we did the method call ConsumerManager.authenticate() with the URL which we 
receive
from the response. I can not explain why I run into the situation described 
above. 
I have attached the JSR-196 Auth Module which I have developed. Maybe you can 
take a
Look at this code. 
I also asked a long time before if I may contribute this code to your project? 
But I
did not yet receive an answer. Maybe this JSR-196 Module is useful. 
I have written a blog about this implementation

http://www-02.imixs.com/roller/ralphsjavablog/entry/openid_serverauthmodule_jsr_
196_with

Original comment by atari.60...@gmail.com on 24 Mar 2010 at 9:15

Attachments:

GoogleCodeExporter commented 9 years ago
ConsumerManager.authenticate() should be called with the return URL that the 
consumer/RP has configured for receiving and handling authentication responses, 
not 
with the value received in such an authentication response.

Original comment by Johnny.B...@gmail.com on 24 Mar 2010 at 5:45