Using with mono 2.4
33 views
Skip to first unread message
Derek Ekins
May 13, 2009, 9:38:07 AM5/13/09
to dotnetopenid
Hi,
I am trying to use this lib on mono.
I noticed a thread from about a year ago that discussed this and
suggested a patch, but it looks like the project has changed a lot
since then.
I got everything integrated and running on the ms.net stack and then
moved it to linux+mono.
I received an error from UntrustedWebRequestHandler (line 38) where it
tries to use HttpWebRequest.DefaultCachePolicy - this is not
implemented in mono so it throws an error. I had a look around and
nowhere is this value actually used. So I took it out and it compiles
fine. But now when I try to login I get some unexpected behaviour.
If I use my myopenid.com account I end up being taken to my profile
page. If I use my google account it says that "No OpenID endpoint
found".
Any ideas what would be causing this?
Thanks,
Derek
I am trying to use this lib on mono.
I noticed a thread from about a year ago that discussed this and
suggested a patch, but it looks like the project has changed a lot
since then.
I got everything integrated and running on the ms.net stack and then
moved it to linux+mono.
I received an error from UntrustedWebRequestHandler (line 38) where it
tries to use HttpWebRequest.DefaultCachePolicy - this is not
implemented in mono so it throws an error. I had a look around and
nowhere is this value actually used. So I took it out and it compiles
fine. But now when I try to login I get some unexpected behaviour.
If I use my myopenid.com account I end up being taken to my profile
page. If I use my google account it says that "No OpenID endpoint
found".
Any ideas what would be causing this?
Thanks,
Derek
Andrew Arnott
May 13, 2009, 9:58:54 AM5/13/09
to dotnet...@googlegroups.com
Hi Derek,
If that cache policy line was the only thing you changed then Mono has come a long way in the last year. It has nothing to do with the misbehavior your seeing though. Mono likely has a behavioral bug that is causing it.
If anyone else has tried it, please speak up. In the mean time, I'll download mono and see if I can figure out what's going on. It's probably worth filing a bug with mono once we can narrow it down.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
If that cache policy line was the only thing you changed then Mono has come a long way in the last year. It has nothing to do with the misbehavior your seeing though. Mono likely has a behavioral bug that is causing it.
If anyone else has tried it, please speak up. In the mean time, I'll download mono and see if I can figure out what's going on. It's probably worth filing a bug with mono once we can narrow it down.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Derek Ekins
May 13, 2009, 10:03:59 AM5/13/09
to dotnet...@googlegroups.com
I still had to compile it on windows - there were lots of dependency problems when compiling on mono.
I am trying to look into this further atm but I can't debug it when running under mono so it is pretty hard to see what is going on.
I am trying to look into this further atm but I can't debug it when running under mono so it is pretty hard to see what is going on.
2009/5/13 Andrew Arnott <andrew...@gmail.com>
Andrew Arnott
May 13, 2009, 10:16:55 AM5/13/09
to dotnet...@googlegroups.com
Well, let's turn up the logging verbosity in DNOA and hope it tells us
what we need to know.
what we need to know.
--
Derek Ekins
May 13, 2009, 10:42:29 AM5/13/09
to dotnet...@googlegroups.com
Good call on the logging!
Found the problem.
Mono doesn't trust any certs by default (http://mono-project.com/UsingTrustedRootsRespectfully)
That link tells you how to trust certs.
Anyway the upshot is it now works beautifully :)
Is that CachePolicy variable actually needed? If not can we remove it?
Thanks for your help!
Found the problem.
Mono doesn't trust any certs by default (http://mono-project.com/UsingTrustedRootsRespectfully)
That link tells you how to trust certs.
Anyway the upshot is it now works beautifully :)
Is that CachePolicy variable actually needed? If not can we remove it?
Thanks for your help!
2009/5/13 Andrew Arnott <andrew...@gmail.com>
Andrew Arnott
May 13, 2009, 10:59:39 AM5/13/09
to dotnet...@googlegroups.com
Hi Derek,
It took a few minutes, but I got one of the sample RPs running on mono on Windows. I had to add to the MONO_PATH to include some dependency DLLs, and I had to remove the <defaultProxy> element from web.config, and of course I had to remove the cache policy field you mentioned. But yes, the RP worked (mostly) after that.
I say mostly because for some reason the home page of OpenIdRelyingPartyWebForms isn't fully rendered. (it's missing the link to the members only page). That's worth a mono bug right there.
Anyway, that field you had to remove looks like it was added for an idea that didn't end up sticking. So yes, future releases will have it removed. Thanks for bringing this up.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
It took a few minutes, but I got one of the sample RPs running on mono on Windows. I had to add to the MONO_PATH to include some dependency DLLs, and I had to remove the <defaultProxy> element from web.config, and of course I had to remove the cache policy field you mentioned. But yes, the RP worked (mostly) after that.
I say mostly because for some reason the home page of OpenIdRelyingPartyWebForms isn't fully rendered. (it's missing the link to the members only page). That's worth a mono bug right there.
Anyway, that field you had to remove looks like it was added for an idea that didn't end up sticking. So yes, future releases will have it removed. Thanks for bringing this up.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Derek Ekins
May 13, 2009, 11:06:16 AM5/13/09
to dotnet...@googlegroups.com
Great.
I am not using any of the webforms integration so didn't have any of those problems...
Just realised I had only tested it with google open id.. just tried it with myopenid.com and it is failing still.. will keep looking into it
I am not using any of the webforms integration so didn't have any of those problems...
Just realised I had only tested it with google open id.. just tried it with myopenid.com and it is failing still.. will keep looking into it
Andrew Arnott
May 13, 2009, 11:28:51 AM5/13/09
to dotnet...@googlegroups.com
Let us know how your investigation progresses, by all means.
I can't test any further because I'm at work, and mono seems to have issues with every new proxy tag I add to web.config, so I'll have to wait till I get home. (probably better that way anyway)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
I can't test any further because I'm at work, and mono seems to have issues with every new proxy tag I add to web.config, so I'll have to wait till I get home. (probably better that way anyway)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Derek Ekins
May 13, 2009, 12:03:15 PM5/13/09
to dotnet...@googlegroups.com
It is failing with:
An error occurred while trying to create an association with http://dereke.myopenid.com/. DotNetOpenAuth.Messaging.ProtocolException: Cannot decode Key-
Value Form because a line was found without a ':' character. (line 2: '<html>') ---> System.FormatException: Cannot decode Key-Value Form because a line was found without a ':' character. (line 2: '
<html>')
This is from the AssociationManager class.
I notice that just before this that (on mono) it says that it is using SHA1:
openid.assoc_type: HMAC-SHA1
openid.session_type: DH-SHA1
but on ms.net it says:
openid.assoc_type: HMAC-SHA256
openid.session_type: DH-SHA256
not sure why it is using a different encryption method.
Would this be a problem? Can you re-configure that?
An error occurred while trying to create an association with http://dereke.myopenid.com/. DotNetOpenAuth.Messaging.ProtocolException: Cannot decode Key-
Value Form because a line was found without a ':' character. (line 2: '<html>') ---> System.FormatException: Cannot decode Key-Value Form because a line was found without a ':' character. (line 2: '
<html>')
This is from the AssociationManager class.
I notice that just before this that (on mono) it says that it is using SHA1:
openid.assoc_type: HMAC-SHA1
openid.session_type: DH-SHA1
but on ms.net it says:
openid.assoc_type: HMAC-SHA256
openid.session_type: DH-SHA256
not sure why it is using a different encryption method.
Would this be a problem? Can you re-configure that?
2009/5/13 Andrew Arnott <andrew...@gmail.com>
Andrew Arnott
May 13, 2009, 12:11:12 PM5/13/09
to dotnet...@googlegroups.com
Derek,
Can you include the entire log of the exchange? For OpenID 2.0 providers, DNOA first tries SHA256 and falls back to SHA1 if the OP asks it to. myopenid.com shouldn't be asking it to, so there's an interesting bug somewhere... seeing the entire log may help me figure out what's going on.
The Key-Value Form error you're getting happens when the OP sends back an illegal response from its OP endpoint. But I suspect the request isn't being correctly formulated (mono problem most likely) so myopenid.com may be getting confused.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Can you include the entire log of the exchange? For OpenID 2.0 providers, DNOA first tries SHA256 and falls back to SHA1 if the OP asks it to. myopenid.com shouldn't be asking it to, so there's an interesting bug somewhere... seeing the entire log may help me figure out what's going on.
The Key-Value Form error you're getting happens when the OP sends back an illegal response from its OP endpoint. But I suspect the request isn't being correctly formulated (mono problem most likely) so myopenid.com may be getting confused.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Derek Ekins
May 13, 2009, 12:22:41 PM5/13/09
to dotnet...@googlegroups.com
Log attached.
I also notice on the last line (trimmed):
Redirecting to http://dereke.myopenid.com/?openid.identity=http%3a%2f%2fdereke.myopenid.com
however when running on ms.net it does this redirect:
Redirecting to http://www.myopenid.com/server?openid.claimed_id=http%3a%2f%2fdereke.myopenid.com%2f&openid.identity=http%3a%2f%2fdereke.myopenid.com
If I replace derek.myopenid.com? with www.myopenid.com/server? the request does actually work.
So I guess there are two problems here. The exception that gets created earlier on, and then redirecting to the wrong place here.
Sorry I am not familiar with the code base so am probably not being much help!
I also notice on the last line (trimmed):
Redirecting to http://dereke.myopenid.com/?openid.identity=http%3a%2f%2fdereke.myopenid.com
however when running on ms.net it does this redirect:
Redirecting to http://www.myopenid.com/server?openid.claimed_id=http%3a%2f%2fdereke.myopenid.com%2f&openid.identity=http%3a%2f%2fdereke.myopenid.com
If I replace derek.myopenid.com? with www.myopenid.com/server? the request does actually work.
So I guess there are two problems here. The exception that gets created earlier on, and then redirecting to the wrong place here.
Sorry I am not familiar with the code base so am probably not being much help!
Andrew Arnott
May 13, 2009, 12:29:36 PM5/13/09
to dotnet...@googlegroups.com
On the contrary, Derek, you're being very helpful. The log was great. Here's the problem:
13-05-2009 17:16:46,626 DEBUG [10] HTTP GET http://dereke.myopenid.com/?xrds=1 (Http:0)
13-05-2009 17:16:47,086 DEBUG [10] Total services discovered in XRDS: 3 (Yadis:0)
13-05-2009 17:16:47,086 DEBUG [10] [{
ClaimedIdentifier: http://dereke.myopenid.com/
ProviderLocalIdentifier: http://dereke.myopenid.com/
ProviderEndpoint: http://dereke.myopenid.com/
OpenID version: 1.0
Service Type URIs:
http://openid.net/signon/1.0
http://openid.net/sreg/1.0
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
}
Notice the provider endpoint matches your claimedidentifier. That's wrong. That should be the OP endpoint http://www.myopenid.com/server. I can only guess that there's something that mono is getting wrong in XML parsing or the LINQ that DNOA uses in processing the XRDS file that is causing the OP endpoint to get lost and this other URL to be used instead.
Can't repro it at work as I said before, unfortunately. But if you've figured out how to get the debugger going, setting a breakpoint at the early discovery phase (just before the ServiceEndpoint is constructed) should help you figure out what's going wrong.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
13-05-2009 17:16:46,626 DEBUG [10] HTTP GET http://dereke.myopenid.com/?xrds=1 (Http:0)
13-05-2009 17:16:47,086 DEBUG [10] Total services discovered in XRDS: 3 (Yadis:0)
13-05-2009 17:16:47,086 DEBUG [10] [{
ClaimedIdentifier: http://dereke.myopenid.com/
ProviderLocalIdentifier: http://dereke.myopenid.com/
ProviderEndpoint: http://dereke.myopenid.com/
OpenID version: 1.0
Service Type URIs:
http://openid.net/signon/1.0
http://openid.net/sreg/1.0
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
}
Notice the provider endpoint matches your claimedidentifier. That's wrong. That should be the OP endpoint http://www.myopenid.com/server. I can only guess that there's something that mono is getting wrong in XML parsing or the LINQ that DNOA uses in processing the XRDS file that is causing the OP endpoint to get lost and this other URL to be used instead.
Can't repro it at work as I said before, unfortunately. But if you've figured out how to get the debugger going, setting a breakpoint at the early discovery phase (just before the ServiceEndpoint is constructed) should help you figure out what's going wrong.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire
Derek Ekins
May 13, 2009, 3:08:26 PM5/13/09
to dotnet...@googlegroups.com
Unfortunately there is no way to debug this unless I can get it building on linux. You can't debug mono on windows is what I am told :(
It has been an exercise in frustration so far!
So it comes into this method CreateServiceEndpoints runs this function xrds.GenerateOPIdentifierServiceEndpoints(claimedIdentifier)
and returns no results
so then it runs this xrds.GenerateClaimedIdentifierServiceEndpoints(claimedIdentifier, userSuppliedIdentifier)
which executes this
from service in xrds.FindClaimedIdentifierServices()
from uri in service.UriElements
where uri.Uri != null
let providerEndpoint = new ProviderEndpointDescription(uri.Uri, service.TypeElementUris)
select ServiceEndpoint.CreateForClaimedIdentifier(claimedIdentifier, userSuppliedIdentifier, service.ProviderLocalIdentifier, providerEndpoint, service.Priority, uri.Priority);
note that it uses the method FindClaimedIdentifierServices
this makes it use the identifier url as the provider url
I can't really see why this would ever be useful?
But I guess the GenerateOPIdentifierServiceEndpoints method should return something.
This is confusing the heck out of me. Not really too sure where to go from here.
Any ideas?
It has been an exercise in frustration so far!
So it comes into this method CreateServiceEndpoints runs this function xrds.GenerateOPIdentifierServiceEndpoints(claimedIdentifier)
and returns no results
so then it runs this xrds.GenerateClaimedIdentifierServiceEndpoints(claimedIdentifier, userSuppliedIdentifier)
which executes this
from service in xrds.FindClaimedIdentifierServices()
from uri in service.UriElements
where uri.Uri != null
let providerEndpoint = new ProviderEndpointDescription(uri.Uri, service.TypeElementUris)
select ServiceEndpoint.CreateForClaimedIdentifier(claimedIdentifier, userSuppliedIdentifier, service.ProviderLocalIdentifier, providerEndpoint, service.Priority, uri.Priority);
note that it uses the method FindClaimedIdentifierServices
this makes it use the identifier url as the provider url
I can't really see why this would ever be useful?
But I guess the GenerateOPIdentifierServiceEndpoints method should return something.
This is confusing the heck out of me. Not really too sure where to go from here.
Any ideas?
2009/5/13 Andrew Arnott <andrew...@gmail.com>
Derek Ekins
May 13, 2009, 5:15:08 PM5/13/09
to dotnet...@googlegroups.com
Allright I found the problem!!
Seems it is a bug in mono - I think in the XPathNavigator.
For some reason the first time you access the Uri property on UriElement it will get the correct value but when it is accessed again later it gets the wrong value. I am not sure where it is being moved on, but it works in ms.net and not mono.
So I made a change so that when the UriElement is created it gets the value and assigns it to a field.
I couldn't figure out how to use git properly but did manage to get the contents of a patch which is attached. It is for two files.. not sure how it is really supposed to be formatted..
I need to try and figure out why this is occuring so I can make a bug report to mono so if you get a chance to have a look and see what is going on please let me know.
Thanks for your help!
Seems it is a bug in mono - I think in the XPathNavigator.
For some reason the first time you access the Uri property on UriElement it will get the correct value but when it is accessed again later it gets the wrong value. I am not sure where it is being moved on, but it works in ms.net and not mono.
So I made a change so that when the UriElement is created it gets the value and assigns it to a field.
I couldn't figure out how to use git properly but did manage to get the contents of a patch which is attached. It is for two files.. not sure how it is really supposed to be formatted..
I need to try and figure out why this is occuring so I can make a bug report to mono so if you get a chance to have a look and see what is going on please let me know.
Thanks for your help!
2009/5/13 Derek Ekins <de...@spathi.com>
Andrew Arnott
May 13, 2009, 8:26:50 PM5/13/09
to dotnetopenid
Excellent. Thanks for drilling into this. I'll see if I can narrow it down further into a reasonable bug report for the mono folks and report back here.
I haven't reviewed your patch thoroughly yet but plan to do so. I've created a new mono2 branch of DNOA though where I can check it in for those wanting to run on mono to capture whatever patches must be applied.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
I haven't reviewed your patch thoroughly yet but plan to do so. I've created a new mono2 branch of DNOA though where I can check it in for those wanting to run on mono to capture whatever patches must be applied.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
2009/5/13 Derek Ekins <de...@spathi.com>
Andrew Arnott
May 20, 2009, 11:45:09 PM5/20/09
to dotnetopenid
Hi Derek,
I'm sorry it's been a week and I haven't had time to drill into this any further. Anything you can do to figure out exactly what's wrong with XPathNavigator in mono or to get as close to it as you can and file a bug with mono would be excellent. DNOA is open source, so if all you can do is offer a repro that involves the library and a few hints of what you've found, that might be enough for the mono community to figure it out.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
I'm sorry it's been a week and I haven't had time to drill into this any further. Anything you can do to figure out exactly what's wrong with XPathNavigator in mono or to get as close to it as you can and file a bug with mono would be excellent. DNOA is open source, so if all you can do is offer a repro that involves the library and a few hints of what you've found, that might be enough for the mono community to figure it out.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
sztupy
Jun 17, 2009, 10:06:18 PM6/17/09
to dotnetopenid
Hi!
I also wanted to run DNOI under mono 2.4. I've chosen the latest from
the 2.5 branch, because I thought it was more stable, but I encounter
the same bugs unfortunately.
For me the problem was with google's openid provider. It sent me 4
services:
<URI>https://www.google.com/accounts/o8/ud</URI>
<URI>https://www.google.com/accounts/o8/ud?source=mail</URI>
<URI>https://www.google.com/accounts/o8/ud?source=gmail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
From which some method created this:
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
So the count stayed, but the content was garbled up. After hours of
putting Logger.Debug messages all over the place this was the point
where I found the error:
[XrdElement.cs; searchForServiceTypUris method]
foreach (XPathNavigator service in Node.Select(xpath.ToString(),
XmlNamespaceResolver)) {
var se = new ServiceElement(service, this);
foreach (var u in se.UriElements)
{
Logger.Debug(u.Uri.ToString());
}
services.Add(se);
}
foreach (var srv in services)
foreach (var u in srv.UriElements)
{
Logger.Debug(u.Uri.ToString());
}
}
Here, in the first loop I get 4 separate URIs, but after adding them
to the list and querying them again, I only get the last one back four
times.
Seems like the problem is with XPathNavigator, and indeed, replacing
var se = new ServiceElement(service, this);
with
var se = new ServiceElement(service.Clone(), this);
solved the problem in this case. Seems like this is some kind of
referencing problem of some sort.
I try to track down some further issues with DNOI under mono,
hopefully most of the other bugs are caused by this issue too.
Regards,
Zsolt Sz. Sztupák
On máj. 21, 05:45, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Hi Derek,
>
> I'm sorry it's been a week and I haven't had time to drill into this any
> further. Anything you can do to figure out exactly what's wrong with
> XPathNavigator in mono or to get as close to it as you can and file a bug
> with mono would be excellent. DNOA is open source, so if all you can do is
> offer a repro that involves the library and a few hints of what you've
> found, that might be enough for the mono community to figure it out.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> >>> 2009/5/13 Andrew Arnott <andrewarn...@gmail.com>
> >>>>>http://www.myopenid.com/server?openid.claimed_id=http%3a%2f%2fdereke....
>
> >>>>> If I replace derek.myopenid.com? withwww.myopenid.com/server?the
>
> tovább »- Idézett szöveg elrejtése -
>
> - Idézett szöveg megjelenítése -
I also wanted to run DNOI under mono 2.4. I've chosen the latest from
the 2.5 branch, because I thought it was more stable, but I encounter
the same bugs unfortunately.
For me the problem was with google's openid provider. It sent me 4
services:
<URI>https://www.google.com/accounts/o8/ud</URI>
<URI>https://www.google.com/accounts/o8/ud?source=mail</URI>
<URI>https://www.google.com/accounts/o8/ud?source=gmail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
From which some method created this:
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
<URI>https://www.google.com/accounts/o8/ud?source=googlemail.com</URI>
So the count stayed, but the content was garbled up. After hours of
putting Logger.Debug messages all over the place this was the point
where I found the error:
[XrdElement.cs; searchForServiceTypUris method]
foreach (XPathNavigator service in Node.Select(xpath.ToString(),
XmlNamespaceResolver)) {
var se = new ServiceElement(service, this);
foreach (var u in se.UriElements)
{
Logger.Debug(u.Uri.ToString());
}
services.Add(se);
}
foreach (var srv in services)
foreach (var u in srv.UriElements)
{
Logger.Debug(u.Uri.ToString());
}
}
Here, in the first loop I get 4 separate URIs, but after adding them
to the list and querying them again, I only get the last one back four
times.
Seems like the problem is with XPathNavigator, and indeed, replacing
var se = new ServiceElement(service, this);
with
var se = new ServiceElement(service.Clone(), this);
solved the problem in this case. Seems like this is some kind of
referencing problem of some sort.
I try to track down some further issues with DNOI under mono,
hopefully most of the other bugs are caused by this issue too.
Regards,
Zsolt Sz. Sztupák
On máj. 21, 05:45, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Hi Derek,
>
> I'm sorry it's been a week and I haven't had time to drill into this any
> further. Anything you can do to figure out exactly what's wrong with
> XPathNavigator in mono or to get as close to it as you can and file a bug
> with mono would be excellent. DNOA is open source, so if all you can do is
> offer a repro that involves the library and a few hints of what you've
> found, that might be enough for the mono community to figure it out.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
> >>>> On the contrary, Derek, you're being very helpful. The log was great.
> >>>> Here's the problem:
>
> >>>> 13-05-2009 17:16:46,626 DEBUG [10] HTTP GET
> >>>>http://dereke.myopenid.com/?xrds=1(Http:0)
> >>>> On the contrary, Derek, you're being very helpful. The log was great.
> >>>> Here's the problem:
>
> >>>> 13-05-2009 17:16:46,626 DEBUG [10] HTTP GET
> >>>> 13-05-2009 17:16:47,086 DEBUG [10] Total services discovered in XRDS: 3
> >>>> (Yadis:0)
> >>>> 13-05-2009 17:16:47,086 DEBUG [10] [{
> >>>> ClaimedIdentifier:http://dereke.myopenid.com/
> >>>> ProviderLocalIdentifier:http://dereke.myopenid.com/
> >>>> * ProviderEndpoint:http://dereke.myopenid.com/*
> >>>> (Yadis:0)
> >>>> 13-05-2009 17:16:47,086 DEBUG [10] [{
> >>>> ClaimedIdentifier:http://dereke.myopenid.com/
> >>>> ProviderLocalIdentifier:http://dereke.myopenid.com/
> >>>> OpenID version: 1.0
> >>>> Service Type URIs:
> >>>> http://openid.net/signon/1.0
> >>>> http://openid.net/sreg/1.0
> >>>> http://openid.net/extensions/sreg/1.1
>
> >>>>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
> >>>> http://openid.net/srv/ax/1.0
> >>>> }
>
> >>>> Notice the provider endpoint matches your claimedidentifier. That's
> >>>> wrong. That should be the OP endpointhttp://www.myopenid.com/server.
> >>>> Service Type URIs:
> >>>> http://openid.net/signon/1.0
> >>>> http://openid.net/sreg/1.0
> >>>> http://openid.net/extensions/sreg/1.1
>
> >>>>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
> >>>> http://openid.net/srv/ax/1.0
> >>>> }
>
> >>>> Notice the provider endpoint matches your claimedidentifier. That's
> >>>> I can only guess that there's something that mono is getting wrong in XML
> >>>> parsing or the LINQ that DNOA uses in processing the XRDS file that is
> >>>> causing the OP endpoint to get lost and this other URL to be used instead.
>
> >>>> Can't repro it at work as I said before, unfortunately. But if you've
> >>>> figured out how to get the debugger going, setting a breakpoint at the early
> >>>> discovery phase (just before the ServiceEndpoint is constructed) should help
> >>>> you figure out what's going wrong.
>
> >>>> --
> >>>> Andrew Arnott
> >>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>> death your right to say it." - Voltaire
>
> >>>> On Wed, May 13, 2009 at 9:22 AM, Derek Ekins <de...@spathi.com> wrote:
>
> >>>>> Log attached.
>
> >>>>> I also notice on the last line (trimmed):
> >>>>> Redirecting to
> >>>>>http://dereke.myopenid.com/?openid.identity=http%3a%2f%2fdereke.myope...
> >>>> parsing or the LINQ that DNOA uses in processing the XRDS file that is
> >>>> causing the OP endpoint to get lost and this other URL to be used instead.
>
> >>>> Can't repro it at work as I said before, unfortunately. But if you've
> >>>> figured out how to get the debugger going, setting a breakpoint at the early
> >>>> discovery phase (just before the ServiceEndpoint is constructed) should help
> >>>> you figure out what's going wrong.
>
> >>>> --
> >>>> Andrew Arnott
> >>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>> death your right to say it." - Voltaire
>
> >>>> On Wed, May 13, 2009 at 9:22 AM, Derek Ekins <de...@spathi.com> wrote:
>
> >>>>> Log attached.
>
> >>>>> I also notice on the last line (trimmed):
> >>>>> Redirecting to
> >>>>>http://www.myopenid.com/server?openid.claimed_id=http%3a%2f%2fdereke....
>
> >>>>> If I replace derek.myopenid.com? withwww.myopenid.com/server?the
> >>>>> request does actually work.
> >>>>> So I guess there are two problems here. The exception that gets created
> >>>>> earlier on, and then redirecting to the wrong place here.
>
> >>>>> Sorry I am not familiar with the code base so am probably not being
> >>>>> much help!
>
> >>>>> 2009/5/13 Andrew Arnott <andrewarn...@gmail.com>
> >>>>> So I guess there are two problems here. The exception that gets created
> >>>>> earlier on, and then redirecting to the wrong place here.
>
> >>>>> Sorry I am not familiar with the code base so am probably not being
> >>>>> much help!
>
>
> >>>>>> Derek,
>
> >>>>>> Can you include the entire log of the exchange? For OpenID 2.0
> >>>>>> providers, DNOA first tries SHA256 and falls back to SHA1 if the OP asks it
> >>>>>> to. myopenid.com shouldn't be asking it to, so there's an
> >>>>>> interesting bug somewhere... seeing the entire log may help me figure out
> >>>>>> what's going on.
>
> >>>>>> The Key-Value Form error you're getting happens when the OP sends back
> >>>>>> an illegal response from its OP endpoint. But I suspect the request isn't
> >>>>>> being correctly formulated (mono problem most likely) so myopenid.commay be getting confused.
> >>>>>> Derek,
>
> >>>>>> Can you include the entire log of the exchange? For OpenID 2.0
> >>>>>> providers, DNOA first tries SHA256 and falls back to SHA1 if the OP asks it
> >>>>>> to. myopenid.com shouldn't be asking it to, so there's an
> >>>>>> interesting bug somewhere... seeing the entire log may help me figure out
> >>>>>> what's going on.
>
> >>>>>> The Key-Value Form error you're getting happens when the OP sends back
> >>>>>> an illegal response from its OP endpoint. But I suspect the request isn't
>
> >>>>>> --
> >>>>>> Andrew Arnott
> >>>>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>>>> death your right to say it." - Voltaire
>
> >>>>>> On Wed, May 13, 2009 at 9:03 AM, Derek Ekins <de...@spathi.com>wrote:
>
> >>>>>>> It is failing with:
> >>>>>>> An error occurred while trying to create an association with
> >>>>>>>http://dereke.myopenid.com/.
> >>>>>>> DotNetOpenAuth.Messaging.ProtocolException: Cannot decode Key-
> >>>>>>> Value Form because a line was found without a ':' character. (line
> >>>>>>> 2: '<html>') ---> System.FormatException: Cannot decode Key-Value Form
> >>>>>>> because a line was found without a ':' character. (line 2: '
> >>>>>>> <html>')
>
> >>>>>>> This is from the AssociationManager class.
>
> >>>>>>> I notice that just before this that (on mono) it says that it is
> >>>>>>> using SHA1:
> >>>>>>> openid.assoc_type: HMAC-SHA1
> >>>>>>> openid.session_type: DH-SHA1
>
> >>>>>>> but on ms.net it says:
> >>>>>>> openid.assoc_type: HMAC-SHA256
> >>>>>>> openid.session_type: DH-SHA256
>
> >>>>>>> not sure why it is using a different encryption method.
> >>>>>>> Would this be a problem? Can you re-configure that?
>
> >>>>>>> 2009/5/13 Andrew Arnott <andrewarn...@gmail.com>
> >>>>>> --
> >>>>>> Andrew Arnott
> >>>>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>>>> death your right to say it." - Voltaire
>
> >>>>>> On Wed, May 13, 2009 at 9:03 AM, Derek Ekins <de...@spathi.com>wrote:
>
> >>>>>>> It is failing with:
> >>>>>>> An error occurred while trying to create an association with
> >>>>>>>http://dereke.myopenid.com/.
> >>>>>>> DotNetOpenAuth.Messaging.ProtocolException: Cannot decode Key-
> >>>>>>> Value Form because a line was found without a ':' character. (line
> >>>>>>> 2: '<html>') ---> System.FormatException: Cannot decode Key-Value Form
> >>>>>>> because a line was found without a ':' character. (line 2: '
> >>>>>>> <html>')
>
> >>>>>>> This is from the AssociationManager class.
>
> >>>>>>> I notice that just before this that (on mono) it says that it is
> >>>>>>> using SHA1:
> >>>>>>> openid.assoc_type: HMAC-SHA1
> >>>>>>> openid.session_type: DH-SHA1
>
> >>>>>>> but on ms.net it says:
> >>>>>>> openid.assoc_type: HMAC-SHA256
> >>>>>>> openid.session_type: DH-SHA256
>
> >>>>>>> not sure why it is using a different encryption method.
> >>>>>>> Would this be a problem? Can you re-configure that?
>
>
> >>>>>>>> Let us know how your investigation progresses, by all means.
>
> >>>>>>>> I can't test any further because I'm at work, and mono seems to have
> >>>>>>>> issues with every new proxy tag I add to web.config, so I'll have to wait
> >>>>>>>> till I get home. (probably better that way anyway)
>
> >>>>>>>> --
> >>>>>>>> Andrew Arnott
> >>>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>>>>>> death your right to say it." - Voltaire
>
> >>>>>>>> On Wed, May 13, 2009 at 8:06 AM, Derek Ekins <de...@spathi.com>wrote:
>
> >>>>>>>>> Great.
> >>>>>>>>> I am not using any of the webforms integration so didn't have any
> >>>>>>>>> of those problems...
> >>>>>>>>> Just realised I had only tested it with google open id.. just tried
> >>>>>>>>> it with myopenid.com and it is failing still.. will keep looking
> >>>>>>>>> into it
>
> >>>>>>>>> 2009/5/13 Andrew Arnott <andrewarn...@gmail.com>
> >>>>>>>> Let us know how your investigation progresses, by all means.
>
> >>>>>>>> I can't test any further because I'm at work, and mono seems to have
> >>>>>>>> issues with every new proxy tag I add to web.config, so I'll have to wait
> >>>>>>>> till I get home. (probably better that way anyway)
>
> >>>>>>>> --
> >>>>>>>> Andrew Arnott
> >>>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
> >>>>>>>> death your right to say it." - Voltaire
>
> >>>>>>>> On Wed, May 13, 2009 at 8:06 AM, Derek Ekins <de...@spathi.com>wrote:
>
> >>>>>>>>> Great.
> >>>>>>>>> I am not using any of the webforms integration so didn't have any
> >>>>>>>>> of those problems...
> >>>>>>>>> Just realised I had only tested it with google open id.. just tried
> >>>>>>>>> it with myopenid.com and it is failing still.. will keep looking
> >>>>>>>>> into it
>
>
> >>>>>>>>>> Hi Derek,
>
> >>>>>>>>>> It took a few minutes, but I got one of the sample RPs running on
> >>>>>>>>>> mono on Windows. I had to add to the MONO_PATH to include some dependency
> >>>>>>>>>> DLLs, and I had to remove the <defaultProxy> element from web.config, and of
> >>>>>>>>>> course I had to remove the cache policy field you mentioned. But yes, the
> >>>>>>>>>> RP worked (mostly) after that.
>
> >>>>>>>>>> I say mostly because for some reason the home page of
> >>>>>>>>>> OpenIdRelyingPartyWebForms isn't fully rendered. (it's missing the link to
> >>>>>>>>>> the members only page). That's worth a mono bug right there.
>
> >>>>>>>>>> Anyway, that field you had to remove looks like it was added for
> >>>>>>>>>> an idea that didn't end up sticking. So yes, future releases will have it
> >>>>>>>>>> removed. Thanks for bringing this up.
> >>>>>>>>>> --
> >>>>>>>>>> Andrew Arnott
>
> ...
> >>>>>>>>>> Hi Derek,
>
> >>>>>>>>>> It took a few minutes, but I got one of the sample RPs running on
> >>>>>>>>>> mono on Windows. I had to add to the MONO_PATH to include some dependency
> >>>>>>>>>> DLLs, and I had to remove the <defaultProxy> element from web.config, and of
> >>>>>>>>>> course I had to remove the cache policy field you mentioned. But yes, the
> >>>>>>>>>> RP worked (mostly) after that.
>
> >>>>>>>>>> I say mostly because for some reason the home page of
> >>>>>>>>>> OpenIdRelyingPartyWebForms isn't fully rendered. (it's missing the link to
> >>>>>>>>>> the members only page). That's worth a mono bug right there.
>
> >>>>>>>>>> Anyway, that field you had to remove looks like it was added for
> >>>>>>>>>> an idea that didn't end up sticking. So yes, future releases will have it
> >>>>>>>>>> removed. Thanks for bringing this up.
> >>>>>>>>>> --
> >>>>>>>>>> Andrew Arnott
>
>
> tovább »- Idézett szöveg elrejtése -
>
> - Idézett szöveg megjelenítése -
sztupy
Jun 17, 2009, 10:27:57 PM6/17/09
to dotnetopenid
Hi!
I've sent a longer message in this group, but google dropped me a 500
server error.
So this time I keep it short.
After hours and lots of debug messages I found a place where
everything breaks. It's in XrdElement.cs / searchForServiceTypeUris
}
Here, if you have more services than one, then although XPathNavigator
will give you back them one by one, after addition only the last one
will remain multiple times. Looks like some referencing / shallow copy
problem. Indeed this one solves the problem:
services.Add(se);
}
It seems under mono you have to clone XPathNavigator. I don't actually
know why this behaviour, but the above solved (one of) the problem I
encountered. Unfortunately I don't know whether this is a bug with
XPathNavigator, foreach, Select, or maybe with yield (this method
invocation was in a multiple nested yield field).
There was another bug however. For a lot of providers I've got a "No
endpoint" exception however they were fine (they worked with the exact
same application but under Win/.net3.5). I'll think I'll track back
this issue after some sleep.
>
>
>
I've sent a longer message in this group, but google dropped me a 500
server error.
So this time I keep it short.
After hours and lots of debug messages I found a place where
everything breaks. It's in XrdElement.cs / searchForServiceTypeUris
method
foreach (XPathNavigator service in Node.Select(xpath.ToString(),
XmlNamespaceResolver))
{
var se = new ServiceElement(service, this);
services.Add(se);
foreach (XPathNavigator service in Node.Select(xpath.ToString(),
XmlNamespaceResolver))
{
var se = new ServiceElement(service, this);
}
Here, if you have more services than one, then although XPathNavigator
will give you back them one by one, after addition only the last one
will remain multiple times. Looks like some referencing / shallow copy
problem. Indeed this one solves the problem:
foreach (XPathNavigator service in Node.Select(xpath.ToString(),
XmlNamespaceResolver))
{
var se = new ServiceElement(service.Clone(), this);
XmlNamespaceResolver))
{
services.Add(se);
}
It seems under mono you have to clone XPathNavigator. I don't actually
know why this behaviour, but the above solved (one of) the problem I
encountered. Unfortunately I don't know whether this is a bug with
XPathNavigator, foreach, Select, or maybe with yield (this method
invocation was in a multiple nested yield field).
There was another bug however. For a lot of providers I've got a "No
endpoint" exception however they were fine (they worked with the exact
same application but under Win/.net3.5). I'll think I'll track back
this issue after some sleep.
> Hi Derek,
>
> I'm sorry it's been a week and I haven't had time to drill into this any
> further. Anything you can do to figure out exactly what's wrong with
> XPathNavigator in mono or to get as close to it as you can and file a bug
> with mono would be excellent. DNOA is open source, so if all you can do is
> offer a repro that involves the library and a few hints of what you've
> found, that might be enough for the mono community to figure it out.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
> On Wed, May 13, 2009 at 5:26 PM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>
> I'm sorry it's been a week and I haven't had time to drill into this any
> further. Anything you can do to figure out exactly what's wrong with
> XPathNavigator in mono or to get as close to it as you can and file a bug
> with mono would be excellent. DNOA is open source, so if all you can do is
> offer a repro that involves the library and a few hints of what you've
> found, that might be enough for the mono community to figure it out.
>
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
>
>
>
>
Andrew Arnott
Jun 18, 2009, 12:17:08 AM6/18/09
to dotnet...@googlegroups.com
Thanks for checking into this. Can everyone who has tried or is trying to get DNOA working on mono review and contribute to the new wiki page I've started on it?
http://dotnetopenauth.net:8000/wiki/mono
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
http://dotnetopenauth.net:8000/wiki/mono
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
sztupy
Jun 18, 2009, 4:10:59 AM6/18/09
to dotnetopenid
Should I switch to the 3.x branch for testing?
> > >wrote:- Idézett szöveg elrejtése -
sztupy
Jun 18, 2009, 8:05:27 AM6/18/09
to dotnetopenid
Switched to 3.1 mono2 branch. Added two more issues to the wiki page:
1. The request and return_to URI do not match under asp.net mvc. This
seems to be because the request URI has the "UrlRouting.axd" string
applied before the query string (example.org/Index/Authenticate/
UrlRouting.axd?query instead of example.org/Index/Authenticate/?query)
This error didn't occur using DNOI 2.5
here is a really ugly hack I used to circumvent this. Unfortunatley I
don't know what was changed between 2.5 and 3.1 that brought this
error:
private void VerifyReturnToMatchesRecipient() {
ErrorUtilities.VerifyProtocol(
string.Equals(this.Recipient.Scheme, this.ReturnTo.Scheme,
StringComparison.OrdinalIgnoreCase) &&
string.Equals(this.Recipient.Authority, this.ReturnTo.Authority,
StringComparison.OrdinalIgnoreCase) &&
string.Equals(this.Recipient.AbsolutePath.Replace
("UrlRouting.axd",""), this.ReturnTo.AbsolutePath,
StringComparison.Ordinal) &&
IsQuerySubsetOf(this.Recipient.Query, this.ReturnTo.Query),
OpenIdStrings.ReturnToParamDoesNotMatchRequestUrl,
Protocol.openid.return_to,
this.ReturnTo,
this.Recipient);
}
2. For some providers (like myopenid) the application redirects to the
identity page, but does nothing else (you'll get the identity page but
without the allow login screen). This was present in 2.5 too. I'm
still trying to find the cause.
Btw. Google and Yahoo! providers work with the mono2 branch.
Zsolt
> > - Idézett szöveg megjelenítése -- Idézett szöveg elrejtése -
1. The request and return_to URI do not match under asp.net mvc. This
seems to be because the request URI has the "UrlRouting.axd" string
applied before the query string (example.org/Index/Authenticate/
UrlRouting.axd?query instead of example.org/Index/Authenticate/?query)
This error didn't occur using DNOI 2.5
here is a really ugly hack I used to circumvent this. Unfortunatley I
don't know what was changed between 2.5 and 3.1 that brought this
error:
private void VerifyReturnToMatchesRecipient() {
ErrorUtilities.VerifyProtocol(
string.Equals(this.Recipient.Scheme, this.ReturnTo.Scheme,
StringComparison.OrdinalIgnoreCase) &&
string.Equals(this.Recipient.Authority, this.ReturnTo.Authority,
StringComparison.OrdinalIgnoreCase) &&
string.Equals(this.Recipient.AbsolutePath.Replace
("UrlRouting.axd",""), this.ReturnTo.AbsolutePath,
StringComparison.Ordinal) &&
IsQuerySubsetOf(this.Recipient.Query, this.ReturnTo.Query),
OpenIdStrings.ReturnToParamDoesNotMatchRequestUrl,
Protocol.openid.return_to,
this.ReturnTo,
this.Recipient);
}
2. For some providers (like myopenid) the application redirects to the
identity page, but does nothing else (you'll get the identity page but
without the allow login screen). This was present in 2.5 too. I'm
still trying to find the cause.
Btw. Google and Yahoo! providers work with the mono2 branch.
Zsolt
sztupy
Jun 18, 2009, 9:40:24 AM6/18/09
to dotnetopenid
Hi again!
Sorry for being a bit chatty on this topic, but I've found the place
where bug no. 2 occurs. Runned the same application on .net3.5 and
mono side by side to check their log. Here is the .net 3.5 one:
ClaimedIdentifier: http://example.myopenid.com/
ProviderLocalIdentifier: http://example.myopenid.com/
ProviderEndpoint: http://www.myopenid.com/server
OpenID version: 2.0
Service Type URIs:
http://specs.openid.net/auth/2.0/signon
ClaimedIdentifier: http://asdf.myopenid.com/
ProviderLocalIdentifier: http://asdf.myopenid.com/
ProviderEndpoint: http://asdf.myopenid.com/
OpenID version: 2.0
Service Type URIs:
http://specs.openid.net/auth/2.0/signon
localidentifier which causes the problems.
The problem was with XPathNavigator too. There seems to be some
serious issues with XPathNavigator, which seems to re-use existing
string references even between methods. This is what I've changed:
(serviceelements.cs)
public IEnumerable<UriElement> UriElements {
get {
List<UriElement> uris = new List<UriElement>();
foreach (XPathNavigator node in Node.Select("xrd:URI",
XmlNamespaceResolver)) {
uris.Add(new UriElement(node.Clone(), this));
}
uris.Sort();
return uris;
}
}
public IEnumerable<TypeElement> TypeElements {
get {
foreach (XPathNavigator node in Node.Select("xrd:Type",
XmlNamespaceResolver)) {
yield return new TypeElement(node.Clone(), this);
}
}
}
I uploaded my changes (I added Clone() to some other places too) to my
github account, but I'm not sure if I've done it right (newer used git
before)
Zsolt Sz. Sztupák
Sorry for being a bit chatty on this topic, but I've found the place
where bug no. 2 occurs. Runned the same application on .net3.5 and
mono side by side to check their log. Here is the .net 3.5 one:
ClaimedIdentifier: http://example.myopenid.com/
ProviderLocalIdentifier: http://example.myopenid.com/
ProviderEndpoint: http://www.myopenid.com/server
OpenID version: 2.0
Service Type URIs:
http://specs.openid.net/auth/2.0/signon
http://openid.net/sreg/1.0
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
and the one from mono:
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
ClaimedIdentifier: http://asdf.myopenid.com/
ProviderLocalIdentifier: http://asdf.myopenid.com/
ProviderEndpoint: http://asdf.myopenid.com/
OpenID version: 2.0
Service Type URIs:
http://specs.openid.net/auth/2.0/signon
http://openid.net/sreg/1.0
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
Under mono the providerendpoint is the same as the claimedidentifier/
http://openid.net/extensions/sreg/1.1
http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
http://openid.net/srv/ax/1.0
localidentifier which causes the problems.
The problem was with XPathNavigator too. There seems to be some
serious issues with XPathNavigator, which seems to re-use existing
string references even between methods. This is what I've changed:
(serviceelements.cs)
public IEnumerable<UriElement> UriElements {
get {
List<UriElement> uris = new List<UriElement>();
foreach (XPathNavigator node in Node.Select("xrd:URI",
XmlNamespaceResolver)) {
uris.Add(new UriElement(node.Clone(), this));
}
uris.Sort();
return uris;
}
}
public IEnumerable<TypeElement> TypeElements {
get {
foreach (XPathNavigator node in Node.Select("xrd:Type",
XmlNamespaceResolver)) {
yield return new TypeElement(node.Clone(), this);
}
}
}
I uploaded my changes (I added Clone() to some other places too) to my
github account, but I'm not sure if I've done it right (newer used git
before)
Zsolt Sz. Sztupák
Andrew Arnott
Jun 18, 2009, 10:13:33 AM6/18/09
to dotnet...@googlegroups.com
Thanks, Zsolt. Don't worry about being chatty. You're providing some great feedback that I'm incorporating into the mono2 branch.
It looks like the two commits you made in your fork of the project in git were made to the master branch rather than the mono2 branch. If you make your changes to the mono2 branch instead I can slurp them up into the main project more quickly and your name appears on the commit message.
Thanks for posting the solution to the TLS cert error!
As far as the returnto verification workaround you did, I won't be incorporating that one since I think I can find a better place to put the fix. The change between DNOI 2.x and DNOA 3.x is in how DNOA looks up the request URL. It changed so that it would correctly figure out the outward facing request URL even in web farm environments. It looks like it uncovered a bug (or difference anyway) in mono. I'll do a bit more prodding to see if I can figure out what's going on there.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
It looks like the two commits you made in your fork of the project in git were made to the master branch rather than the mono2 branch. If you make your changes to the mono2 branch instead I can slurp them up into the main project more quickly and your name appears on the commit message.
Thanks for posting the solution to the TLS cert error!
As far as the returnto verification workaround you did, I won't be incorporating that one since I think I can find a better place to put the fix. The change between DNOI 2.x and DNOA 3.x is in how DNOA looks up the request URL. It changed so that it would correctly figure out the outward facing request URL even in web farm environments. It looks like it uncovered a bug (or difference anyway) in mono. I'll do a bit more prodding to see if I can figure out what's going on there.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
sztupy
Jun 18, 2009, 12:00:56 PM6/18/09
to dotnetopenid
Hi!
Hopefully I managed to get it right this time. It's high time to learn
git...
I have some questions regarding this return_to attribute. Currently
the mono application I'm working on sits behind a firewall. It can
access all external resources, but it can only be acessed using a web
proxy, which sits on the firewall machine.
The problem is that when I run the web application on the internal
server on a different port than 80, then the return_to attribute will
also contain the port number, but that port number is inaccessible
from the outside world. Is there a way to tell DNOA that the port
number shouldn't be sent in the return_to attribute? (Of course I can
change the application to run on port 80 on the internal server, but
that's not an option if I have to deploy more applications that use
OpenID)
Maybe I think I clarify the previous problem:
1. User connects to "someplace.example.org" which is a firewall with a
web server acting as a proxy (actually lighttpd)
2. Lighttpd proxies the request to an internal server that runs on
some other port (like 4000)
3. Everything works fine, until User wants to login using OpenID
4. When logging with OpenID, the provider will return to
someplace.example.org:4000 instead of someplace.example.org
Things like setting fix-redirects in the proxy don't seem to work,
because it only changes the headers that are sent.
Zsolt
Hopefully I managed to get it right this time. It's high time to learn
git...
I have some questions regarding this return_to attribute. Currently
the mono application I'm working on sits behind a firewall. It can
access all external resources, but it can only be acessed using a web
proxy, which sits on the firewall machine.
The problem is that when I run the web application on the internal
server on a different port than 80, then the return_to attribute will
also contain the port number, but that port number is inaccessible
from the outside world. Is there a way to tell DNOA that the port
number shouldn't be sent in the return_to attribute? (Of course I can
change the application to run on port 80 on the internal server, but
that's not an option if I have to deploy more applications that use
OpenID)
Maybe I think I clarify the previous problem:
1. User connects to "someplace.example.org" which is a firewall with a
web server acting as a proxy (actually lighttpd)
2. Lighttpd proxies the request to an internal server that runs on
some other port (like 4000)
3. Everything works fine, until User wants to login using OpenID
4. When logging with OpenID, the provider will return to
someplace.example.org:4000 instead of someplace.example.org
Things like setting fix-redirects in the proxy don't seem to work,
because it only changes the headers that are sent.
Zsolt
Andrew Arnott
Jun 18, 2009, 1:21:04 PM6/18/09
to dotnetopenid
Zsolt,
I'm fixing a few places in DNOA to better track request URLs before and after rewriting that will hopefully either avoid the mono problem or make working around the mono problem more straightforward. I'll keep you apprised.
Regarding your firewall port return_to issue... DNOA does its best to use ASP.NET mechanisms to figure out what the public-facing URL is so it can use that to formulate the return_to URL. It's straightforward enough to manipulate the return_to argument by calling OpenIdRelyingParty.CreateRequest and passing the return_to value explicitly, but that won't solve the return_to verification problem that will cause it to ultimately fail anyway. So you need a way to not just control return_to, but basically override DNOA's normal mechanism of discovering the original request URL. The requirement is the DNOA know what the public URL is (example.someplace.org instead of example.someplace.org:4000), that is, whatever is appearing as the URL in the end user's browser Location bar.
There are two ways to accomplish this. The best way IMO is to configure your firewall to forward the HTTP request to your server while setting the server variable HTTP_HOST to whatever the host (and port if not the default for the scheme) is on the outside. DNOA will pick up on this automatically and then you won't see :4000 any more. This is how Azure and other web farm environments work today.
The alternative way is to call the OpenIdRelyingParty.CreateRequest(...) overload that takes the return_to as I said before, and then when you call OpenIdRelyingParty.GetResponse(...), call the overload that takes an HttpRequestInfo instead of the one that takes no parameters. You can initialize the HttpRequestInfo with the correct outward facing URL and then return_to verification will work correctly as well.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
I'm fixing a few places in DNOA to better track request URLs before and after rewriting that will hopefully either avoid the mono problem or make working around the mono problem more straightforward. I'll keep you apprised.
Regarding your firewall port return_to issue... DNOA does its best to use ASP.NET mechanisms to figure out what the public-facing URL is so it can use that to formulate the return_to URL. It's straightforward enough to manipulate the return_to argument by calling OpenIdRelyingParty.CreateRequest and passing the return_to value explicitly, but that won't solve the return_to verification problem that will cause it to ultimately fail anyway. So you need a way to not just control return_to, but basically override DNOA's normal mechanism of discovering the original request URL. The requirement is the DNOA know what the public URL is (example.someplace.org instead of example.someplace.org:4000), that is, whatever is appearing as the URL in the end user's browser Location bar.
There are two ways to accomplish this. The best way IMO is to configure your firewall to forward the HTTP request to your server while setting the server variable HTTP_HOST to whatever the host (and port if not the default for the scheme) is on the outside. DNOA will pick up on this automatically and then you won't see :4000 any more. This is how Azure and other web farm environments work today.
The alternative way is to call the OpenIdRelyingParty.CreateRequest(...) overload that takes the return_to as I said before, and then when you call OpenIdRelyingParty.GetResponse(...), call the overload that takes an HttpRequestInfo instead of the one that takes no parameters. You can initialize the HttpRequestInfo with the correct outward facing URL and then return_to verification will work correctly as well.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
2009/6/18 sztupy <ma...@sztupy.hu>
Andrew Arnott
Jun 18, 2009, 8:26:48 PM6/18/09
to dotnetopenid
Hurray. My changes to the HTTP request sniffing (happened to?) fix/workaround the mono MVC path issue. I suggest you pull down the latest from the mono2 branch and revert the returnto verification change if you made it.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
Andrew Arnott
Jul 2, 2009, 11:22:22 AM7/2/09
to dotnetopenid
Are those of you who want to run DNOA on mono ultimately interested in getting it to work on Linux? Or is it mono on Windows you want to work?
Reason I ask is up to this point I've done some avoiding of adding references to .NET 3.5 assemblies that I knew mono didn't have, but wouldn't be a problem for mono as long as it ran on Windows and therefore had access to these assemblies. But if no one is interested in mono on Linux then it's a non-issue.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
Reason I ask is up to this point I've done some avoiding of adding references to .NET 3.5 assemblies that I knew mono didn't have, but wouldn't be a problem for mono as long as it ran on Windows and therefore had access to these assemblies. But if no one is interested in mono on Linux then it's a non-issue.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
2009/6/18 Andrew Arnott <andrew...@gmail.com>
Derek Ekins
Jul 2, 2009, 12:08:15 PM7/2/09
to dotnet...@googlegroups.com
I am using it on linux. what assemblies do you want to reference?
On 02/07/2009, Andrew Arnott <andrew...@gmail.com> wrote:
> Are those of you who want to run DNOA on mono ultimately interested in
> getting it to work *on Linux*? Or is it mono on Windows you want to work?
--
Derek Ekins
0789 194 1669
http://externalreflections.co.uk
http://twitter.com/dereke
Andrew Arnott
Jul 2, 2009, 12:36:40 PM7/2/09
to dotnet...@googlegroups.com
There's some awesome design possibilities to make it easier to manage extensibility if I could use http://www.codeplex.com/MEF. But I think MEF includes a small assembly that is not licensed for use on Linux.
So you have DNOA working on Linux? Can you share any steps you had to take to make it work, please? Either by email or on our mono wiki page. That would be awesome.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
So you have DNOA working on Linux? Can you share any steps you had to take to make it work, please? Either by email or on our mono wiki page. That would be awesome.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
Reply all
Reply to author
Forward
0 new messages