Closed GoogleCodeExporter closed 9 years ago
What attribute type URIs were used? Different providers may support different
type
URIs.
Original comment by Johnny.B...@gmail.com
on 25 Mar 2010 at 12:30
I'm not sure about Yahoo, but Google requires the AX alias to be 'ax'.
See: http://code.google.com/apis/accounts/docs/OpenID.html
*Must* be:
openid.ns.ax = 'http://openid.net/srv/ax/1.0'
openid.ax.type.email = 'http://axschema.org/contact/email'
...etc...
You have an existing check for SReg, you just need to add one for AXSchema, to
set
the alias to 'ax'. However, if this is not standard or other providers require
different values, you might want to provide an overload to allow for supplying
the
alias when adding the extension to the message.
For reference:
org.openid4java.message.Message.java:
389: // use the hardcoded "sreg" alias for SREG, for seamless
interoperation
390: // between SREG10/OpenID1 and SREG11/OpenID2
391: if (SRegMessage.OPENID_NS_SREG.equals(typeUri))
392: alias = "sreg";
The problem is that the code needs the ability to specify the attribute alias.
Original comment by mark.ren...@gmail.com
on 18 Apr 2010 at 12:25
Retrieve information from other providers doesn't work also. The problem is
only with
FetchRequest, when I use SRegRequest almost everything is ok.
In comments in http://code.google.com/p/openid4java/wiki/AttributeExchangeHowTo
BlessedGeek resolved the problem, so for developers is only to correct this and
release new version.
quote: Your message class addExtension source code has this: {{{{
public void addExtension(MessageExtension? extension) throws MessageException? {
String typeUri = extension.getTypeUri();
if (hasExtension(typeUri))
throw new MessageException?("Extension already present: " + typeUri);
String alias = "ext" + Integer.toString(++ extCounter);
.........
}
}}}}
Shouldn't it be like this: {{{{
public void addExtension(MessageExtension? extension) throws MessageException? {
String typeUri = extension.getTypeUri();
if (hasExtension(typeUri))
throw new MessageException?("Extension already present: " + typeUri);
String alias = "ax.type";
.........
}
}}}}
Original comment by lwojtys...@gmail.com
on 25 Apr 2010 at 11:06
I am also experiencing this issue. How are people getting around the hardcoded
alias'ing?
Original comment by chad.car...@gmail.com
on 17 Oct 2012 at 9:37
This is not an issue with the library (or the protocol). The alias is up to the
emitter of the message. Requiring a specific/hardcoded alias would be a
violation of the spec.
The google doc is also in line with this: "Google uses the namespace aliases
"ax" for these parameters but you can specify any alias you choose
(openid.ns.<alias>)."
The disconnect is very likely on the attribute type URI required by clients and
provided by OPs. Library users need to confirm the exact type URIs supported by
each party they plan to interact with.
Original comment by Johnny.B...@gmail.com
on 17 Oct 2012 at 9:52
While this original ticket is about AX, it applies to my use case as well with
SREG. I don't see how I can set the extension alias/type URI when adding
fetches to the authRequest. It looks like it's hardcoded to look for specific
typeURI's in the addExtension method in the Message.class
For example, I am working with an OP that doesn't seem to like/accept this:
&openid.ns.sreg=http://openid.net/sreg/1.0.. They completely ignore it.
But after doing some testing/manual URL crafting, it looks like op does
like/accept this:
&openid.ns.sreg=http://openid.net/extensions/sreg/1.1,
But I don't know how I can accomplish this, because as soon as I try to use
SREG11, and use sregReq.setTypeUri(SRegMessage.OPENID_NS_SREG11);
The namespace switches to ext1 due to the hardcoded check for
SRegMessage.OPENID_NS_SREG in the message.class when adding the
extension/building out the aliases.
The only way I can see this working is by changing message.class from:
if (SRegMessage.OPENID_NS_SREG.equals(typeUri))
alias = "sreg";
to be
if
(SRegMessage.OPENID_NS_SREG.equals(typeUri)||SRegMessage.OPENID_NS_SREG11.equals
(typeUri))
alias = "sreg";
This Creates the param statement I think the OP wants..
Modifying a class from the library isn't a valid option... However I do not
know how to set the alias/namespace during the fetch process. As you say, it
should be up to me. But it isn't. To me it looks like the alias is currently
hardcoded against a specific typeURI in the library (message.class).
I'm new to openID so maybe I'm just not understanding this properly.
Original comment by chad.car...@gmail.com
on 18 Oct 2012 at 5:29
Looks like the same underlying (non)issue as with AX.
You can set the extension namespace with the library; the alias is a protocol
detail that shouldn't be exposed to library users; receivers of 2.0 messages
with extensions should process any aliases they receive, extract the associated
namespaces and examine those and decide whether each extension/namespace is
supported or not. Looking directly at namespace aliases is not a specified
behavior.
The SREG 1.0 is an exception / compatibility hack (there was no
extensibility/extension namespaces in OpenID 1.x / SREG 1.0).
I suggest a bug is filed with the OP implementation that doesn't like the
"ext1" alias.
Original comment by Johnny.B...@gmail.com
on 18 Oct 2012 at 6:33
Original comment by Johnny.B...@gmail.com
on 30 Oct 2012 at 11:36
Original issue reported on code.google.com by
Michael.Krog
on 22 Feb 2010 at 2:41