Unable to retrieve attributes(Google & Yahoo at least)

[GoogleCodeExporter]

1. Follow 
http://code.google.com/p/openid4java/wiki/AttributeExchangeHowTo as 
a supplemental to http://code.google.com/p/openid4java/wiki/QuickStart
2. Use the identifier https://www.google.com/accounts/o8/id or 
http://yahoo.com/
3: Retrieve the attributes after login

What is the expected output? What do you see instead?
The loginservice should make me accept sharing firstname, surname and 
email. But instead i get the following:

- when using Google, only email
- when using yahoo, nothing at all.

What version of the product are you using? On what operating system?
openid4java-0.9.5.593 on Mac os.

Original issue reported on code.google.com by Michael.Krog on 22 Feb 2010 at 2:41

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by Johnny.B...@gmail.com on 30 Oct 2012 at 11:36

• Changed state: Invalid