havard / node-openid Goto Github PK
View Code? Open in Web Editor NEWOpenID for Node.js
License: MIT License
OpenID for Node.js
License: MIT License
running sample.js I get https module missing. I am wondering how to fix this(v0.2.6 does not have https module).
alfred@alfred-laptop:~/node/test$ node -v
v0.2.6
alfred@alfred-laptop:~/node/test$ npm -v
0.2.16
alfred@alfred-laptop:~/node/test$ node sample.js
node.js:63
throw e;
^
Error: Cannot find module 'https'
at loadModule (node.js:275:15)
at require (node.js:411:14)
at Object.<anonymous> (/home/alfred/local/lib/node/.npm/openid/0.1.2/package/openid.js:35:13)
at Module._compile (node.js:462:23)
at Module._loadScriptSync (node.js:469:10)
at Module.loadSync (node.js:338:12)
at loadModule (node.js:283:14)
at require (node.js:411:14)
at Object.<anonymous> (/home/alfred/local/lib/node/openid/index.js:11:18)
at Module._compile (node.js:462:23)
Thank you for the great library.
myopenid works, but livejournal.com fails. Try to enter nponeccop.livejournal.com into the box - it doesn't reach the livejournal consent page. It says something like "discovery failed".
When trying to authenticate with phpMyID (e.g., http://phpmyid.com/) using sample.js, the authentication fails with the error: "Claimed identifier in assertion response does not match discovered claimed identifier". It looks like the openid.claimed_id parameter is not set in the callback. Is this a problem with phpMyID? Would it be safe to fall back to openid.identity when openid.claimed_id isn't set?
Here are the parameters that get passed via the callback:
openid.mode=id_res&openid.identity=http%3A%2F%2Fphpmyid.com%2Findex.php&openid.assoc_handle=od66fql3fb8htfp3n9aenjkh66&openid.return_to=http%3A%2F%2Flocalhost%3A3005%2Fverify&openid.signed=mode%2Cidentity%2Cassoc_handle%2Creturn_to&openid.sig=XgvJ8OWE36IKXL706fa3cPa6GaM%3D
_verifyAssertionAgainstProvider()
always checks params['openid.claimed_id']
even though the provider version is 1.x. I'm new to openid, but I think it's wrong. The claimed_id parameter only appears version 2.0.
I'm seeing large CPU spikes when I call openid.authenticate(), one before the request is sent and one after the response is received.
This causes significant latency -- is this a known issue?
I am unsure if this issue is with Yahoo or with your Node OpenId framework. I have noticed in some senario's that Yahoo's authentication will fail. Please try the following:
Pre Test Steps:
Remove your openId Yahoo trust for the sample application
Log out of Yahoo
Run: node sample.js
Enter: http://me.yahoo.com
On the Yahoo page, log in using your Yahoo account.
Received this error:
Authentication failed: Invalid association handle
Close the popup window.
From the sample.js page, try to log on again to Yahoo.
Received this response:
{"authenticated":true,"claimedIdentifier":"https://me.yahoo.com/a/XXXXXXXXXX","nickname":"XXXXX","fullname":"XXXXX"}
I have also noticed issues using Yahoo's alternative logins on the logon page (Facebook & Google). Can you please test those also?
When I try to use http://openid.anonymity.com/venpb2 as claimedIdentifier
with current openid module from npm I get:
Authentication failed: Cannot retain discovered information; the provider does not contain the required attributes
Using my delegate swatinem.de works fine, but verifyAssertion().identifier returns the id I delegate to: swatinem.myopenid.com.
IMO, the point of using a delegate is to be able to transparently switch the id behind the delegate without the relying party noticing.
I will work on this issue when I have time.
This includes:
Yahoo.com authentication doesn't work.
Here are my random thoughts (feel free to throw them away)
See http://developer.yahoo.com/openid/faq.html
Yahoo.com seems to have chosen an obscure part of Yadis protocol for discovery: if you perform
wget -S --header "Accept: application/xrds+xml" http://yahoo.com
You get X-XRDS-Location
response header (in addition to an idiotic response containing another set of headers in response body):
X-XRDS-Location: http://open.login.yahooapis.com/openid20/www.yahoo.com/xrds
Valid json requires double quotes around strings. The current package.json has single quotes.
This means that the openid module will still not work with the latest npm.
I'm having issues getting the sample working in node 0.4.0. Instead of going to the auth server it just sits there waiting for the connection to end. Node 0.4.0 changed the way http.request works but the old api should still work, i'm not sure why on('end') isn't firing.
The latest version of npm requires valid json, as in:
"keys get double quotes": "string values also get double quotes"
I get the distinct feeling I'm doing something incredibly stupid, but I can't seem to get this to do anything. I run sample.js, and pull it up. I fill in https://www.google.com/accounts/o8/id, as per the Google spec (http://code.google.com/apis/accounts/docs/OpenID.html#endpoint). I then get infinite loading, followed by the server giving me an empty response.
Is this a bug? Am I just an idiot?
The Error is: Invalid association handle
I get the Page of wordpress, where I can say, if I trust my Site, but then I get the error from relyingParty.verifyAssertion as callback.
Stepped through it with node-inspector and found that the error is thrown in _checkSignatureUsingAssociation.
The value of params['openid.assoc_handle'] is "{HMAC-SHA1}{4e295ff5}{Ag1CPg==}"
And this Association is not found.
Hope it helps to get Wordpress running.
I put in "https://www.google.com/accounts/o8/id" as open id, and It just never redirect me to google page and just keep loading. I tried with yahoo and it works fine.
i have trouble with openid ver 1.x
510: if(providers == null)
but providers is empty array
510: if(providers == null || providers.length === 0)
seems to correct this..
this gets a 404 (since this isn't an actual url) which ultimately leads to a an empty providers array which results in 'No OpenID provider was discovered for the asserted claimed identifier'.
This use case worked in previous versions of node-openid
I noticed the final version on npm is still 0.1.1. When is it going to updated or am I doing something wrong. I guess install from tarball, but I was wondering.
npm ls | grep openid
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
[email protected] =alfredwesterveld remote Authenticate for Google OpenID
[email protected] =alfredwesterveld remote Authenticate for Google OpenID
[email protected] =alfredwesterveld remote Authenticate for Google OpenID
[email protected] =alfredwesterveld remote Authenticate for Google OpenID
[email protected] =alfredwesterveld remote Authenticate for Google OpenID
[email protected] =alfredwesterveld active installed latest remote Authenticate for Google OpenID
[email protected] =havard remote OpenID 1.1/2.0 library for node.js
[email protected] =havard active installed latest remote OpenID 1.1/2.0 library for node.js
npm ok
Thank you
I am using the claimedIdentifier property of the result, to have a unique ID for my Accounts.
Wordpress is leaving "claimedIdentifier: undefined". In the request to my verify url there is only the property openid.identity set to the Identifier.
How about prefilling claimedIdentifier with this?
What I need is the unique openid-identifier in the result of the verifyAssertion-Method, where I get the Attributes from Attribute Exchange.
Thanks for this great piece of code.
We are using it for Msgboy. It works in most cases. Yet, sometimes, we can't authenticate a given user as
relyingParty.verifyAssertion(req, function(error, result) {
... yields error: { message: 'Invalid signature' }
}
Oddly enough it looks like when our users do retries, it sometimes work, but it can take up to 3 or 4 times (usually, the user will just surrender if that doesn't work at this point).
This is quite annoying, and we would love to find the reason as well as a fix. Any clue? Anything we could do to help fix that?
If the Endpoint URL contains a query string parameter (ex. https://www.google.com/a/myhosteddomain.com/o8/ud?be=o8), the verification function _verifyAssertionAgainstProvider strips this query string from the op_endpoint response parameter but not from the original discovered URL before comparing the two. The result is that even if the two URL's originally matched, we get the following error:
OpenID provider endpoint in assertion response does not match discovered OpenID provider endpoint
Context: I am using Google's Federated Login with OpenID to provide SSO using our Google App account.
https://sites.google.com/site/oauthgoog/fedlogininterp/openiddiscovery
Nice work on this module! Since HTTPS isn't working in Node.js v0.3.x yet, I'm still using v0.2.x and needed the query string parsing to follow the old conventions as well as the new. In case you're not familiar, in v0.2.x the query string parser actually parses on dots (.) to create a request object hierarchy (i.e. 'openid.invalidate_handle=foo' becomes {openid:{invalidate_handle:'foo'}} rather than {'openid.invalidate_handle':'foo'}).
The patch below adds a function that recursively searches the query object for the request key before failing.
https://gist.github.com/774019
Also, I noticed that one of the keys was referencing 'openid.claimed_identifier' rather than 'openid.claimed_id' which is what Google's OpenID implementation returns on successful authentication. I'm not sure if which is the expected behavior, but I couldn't find any documentation on 'openid.claimed_identifier', so I wondered if it might be a typo. You'll notice that the patch above also includes a fix for this.
Let me know if I need to submit the patch in another form. Thanks!
Even though node-openid makes authenticated pretty straight-forward, it might be nice to show specific examples with the most common providers. The top 5 that seem to be most common today are:
I think that making it clear how to work with those providers specifically could greatly increase this module's usage and get people up and running more quickly. Naturally, this would not inhibit the use of other providers, and it would only help to pin down best practices.
When asking for a first name using "http://axschema.org/namePerson/first": "required" I get "Invalid Signature" back from _checkSignatureUsingAssociation. I'm using google as the OpenID provider, and the first name in the google profile is "Börje". "ö" as in ö using html entities :)
Changing the first name in google profiles to something with just A-Za-z I don't get the "Invalid Signature" error anymore.
Am I doing something wrong, or is this a bug in node-openid?
Can this module be used to act as RP for a google apps hosted domain - i.e, Tying to implement "signin with google apps login"
I mean, meta-data and signing is outsourced to google apps as per http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains
Stuck at this error during verifyAssertion phase.
"No OpenID provider was discovered for the asserted claimed identifier".
Is this because the hosted domain does not have host-meta file. Is it possible to fetch meta from the google?
I can work on it and submit a patch if this is indeed not supported yet.
Not an bug or anything else, just in case if anyone wants to specify alias (openid.ax.type.) while doing attribute exchange, you can do some thing like
attribute_exchange_ext = new openid.AttributeExchange({})
attribute_exchange_ext.requestParams['openid.ax.type.custom_id'] = "http://example.com/entity/id";
attribute_exchange_ext.requestParams['openid.ax.required'] = attributeExchange.requestParams['openid.ax.required'] + ",custom_id";
"custom_id" is the alias you want to specify.
I put this information here because I don't know where to put it. Let me know if this information is redundant or it should go to somewhere else. Thanks!
I'm using ExpressJS and the bodyParser middleware automatically parses the body. This means that I cannot simply pass the request to verifyAssertion as the app will hang because the request body has already been read.
I was wondering if we could allow passing the parsed params directly to verifyAssertion, or have the logic check to see if the request body is present. The most important thing is to obviously keep this module framework agnostic, but I'm hoping there is an elegant solution we can reach to this problem.
Thanks!
PAPE extension supports is provided by most providers, Google and Yahoo supports them.
Support from them will help in prompting user to reauthenticate if required, otherwise user cache information will be used.
In openid authenticate function an extra parameter to add pape extension and allow to set set_max_age.
Hey,
The exact example code you've provided in the README file fails for my gmail address. After inputting it into the text box and clicking submit, I'm successfully taken to the gmail auth page, where I'm asked if I want to provide access to "Localhost" (which I say yes to), then when I'm redirected back, I get "Failure :(".
Have you tested this with Gmail?
Curious why the first value passed to the callbacks is the success value. Following the Node convention allows for compatibility with other libraries such as Promised-IO, which expect the first value to be an optional error.
Can this work?
(From sample.js)
var ax = new openid.AttributeExchange(result);
The var result only contains { authenticated: true }.
Note, to use myopenid.com I had to work around issue 26 and that fix may be the cause of this issue.
It seems myopenid.com returns
{
..
version: 'http://specs.openid.net/auth/2.0/signon',
..
}
which messes things up when
if(version.indexOf('2.0') !== -1)
{
params['openid.ns'] = version;
}
is set in _generateAssociationRequestParameters, resulting in a
error: 'Invalid OpenID Namespace u\'http://specs.openid.net/auth/2.0/signon\'',
later on.
Setting openid.ns to "http://specs.openid.net/auth/2.0" works great, but I'm not familiar enough with the openid spec yet to boldly state that as a fix :).
I noticed you updated your package.json and you now require "engines" : { "node" : ">=0.3.6" }
Hello,
I am trying to use Google's Federated Login feature to allow my users to log in through Google. However, whenever I try to use this module to make an authentication request to Google's endpoint (https://www.google.com/accounts/o8/id) the server hangs. None of the callbacks are ever called, and I never get a response back from Google. I have verified that I am able to get to other OpenID providers (specifically, LiveJournal is one I tested).
I am using Node version 0.4.8 and the current version of the module as installed by npm.
Thank you.
Keys must be quoted. (This breaks the package in npm 0.3.0)
Test method:
exports.testSetupAuthenticationWithMyOpenId = function(test)
{
var called = 0;
openid.authenticate('https://swatinem.de',
'http://example.com/verify', null, false, false, function(error, url)
{
assert.ok(called == 0, "callback executed twice");
called++;
assert.ok(url.indexOf('checkid_setup') !== -1);
test.done();
});
}
Call stack:
AssertionError: callback executed twice
at /home/swatinem/Coding/Seiten/nodestuff/node-openid/test/openid_integration_tests.js:36:12
at successOrNext (/home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:764:18)
at _requestAuthentication (/home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:863:3)
at /home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:790:13
at /home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:648:9
at /home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:264:9
at IncomingMessage.<anonymous> (/home/swatinem/Coding/Seiten/nodestuff/node-openid/openid.js:268:32)
at IncomingMessage.emit (events.js:81:20)
at HTTPParser.onMessageComplete (http.js:133:23)
at Socket.ondata (http.js:1221:22)
Simply because thats the first node version where using the google openid actually works.
$node -v
v0.2.6
$node openid.js
/home/alfred/local/lib/node/.npm/openid/0.1.0/package/lib/xrds.js:28
data = data.replace(/\n/g, '');
^
TypeError: Cannot call method 'replace' of undefined
at Object.parse (/home/alfred/local/lib/node/.npm/openid/0.1.0/package/lib/xrds.js:28:15)
at _parseXrds (/home/alfred/local/lib/node/.npm/openid/0.1.0/package/openid.js:246:23)
at /home/alfred/local/lib/node/.npm/openid/0.1.0/package/openid.js:390:20
at IncomingMessage.<anonymous> (/home/alfred/local/lib/node/.npm/openid/0.1.0/package/openid.js:153:38)
at IncomingMessage.emit (events:48:20)
at HTTPParser.onMessageComplete (http:107:23)
at Client.onData [as ondata] (http:854:27)
at IOWatcher.callback (net:494:29)
at node.js:773:9
P.S: I got google openid working, but only when I did npm from the latest tarball.
I guess this is a bigger issue as it would require provider support to test against the library itself against provider.
Tests should include different auth scenarios as well as basic API testing: do extensions work correctly, is the identifier passed down to the caller and much more.
I reported this issue a week ago to the passport-openid tracker, but the issue might stem from within node-openid itself and I've gotten no response on the passport-openid side, so figured I'd pass along the issue.
Here is what I'm getting passed back to me while using the Steam OpenID and I console log out the callback/next for authenticate. I've used Google OpenID and it is working fine.
{ name: 'InternalOpenIDError',
message: 'Failed to discover OP endpoint URL',
openidError: { message: 'No usable providers found for the given identifier' } } }
Additionally, when I'm debugging I'm getting this error from within node-openid:
error: 'Associations not supported'
error_code: 'unsupported-type'
ns: 'http://specs.openid.net/auth/2.0'
It is detecting the correct endpoint and while debugging using node-inspector node-openid's post never seems to complete, which maybe the root problem.
The example app should have 'error.message' instead of just 'error' when an authentication failure occurs.
Using your own sample, I'm unable to use 'hyves.nl' as a OpenId provider.
Some debugging seems to point to the fact that 'hyves.nl' returns an HTTP400 to indicate an 'associate' error with error_code 'unsupported_type', instead of the HTTP200 which your code seems to expect. If I remove the 'statusCode != 200' check on line 707 of openid.js, I finally get the 'hyves.nl' openid login page.
This stil does not solve the entire problem since 'hyves.nl' calls the 'verification url' using a POST with 'application/x-www-form-urlencoded' instead of the params in de URL which your 'openid.verifyAssertion' seems to require. So openid.js throws an exception 'No signature in response', but the signature is there, only not in de URL.
_buildUrl loses query string. Parsed URL just before returning looks like this:
{
protocol: 'https:',
slashes: true,
host: 'www.google.com',
hostname: 'www.google.com',
href: 'https://www.google.com/accounts/o8/site-xrds?hd=example.com',
search: false,
query: 'hd=novembra.com.br',
pathname: '/accounts/o8/site-xrds'
}
And the following URL is returned:
Tried google and yahoo, and could not get the specified values from the provider.
I want to store my OpenID associations in a MongoDB. However, the driver I'm using is asynchronous, making it impossible for me to use it with the current version of node-openid.
I'm sure this isn't an isolated case, thus I suggest to make saveAssociation() and loadAssociation() asynchronous.
Havard:
Thanks for posting this software. I had a small problem with sample.js; it crashes on the first bad openid.
To demonstrate: npm install openid; run "node ./sample.js" in linux with node 0.4.8, access server, enter a bad url as openid
What happens: exception thrown at line 76 res.end(error); server shuts down. I'm aware node.js does that on any uncaught exception.
What I expected to happen instead: receive an error message
Thoughts: line 76 has "res.end(error)"; http response code is set to 500. the variable error only occurs here and is not
otherwise defined in sample.js.
Bandaid: I changed error to 'error' and it doesn't throw exceptions any more. The error message, though, is just "error", doesn't report the 500 in google chrome. I'm not sure what openID should return on bad authentication. Is it 500?
Perhaps the admin using the sample.js is supposed to know to set error to something more reasonable, and the callback acts as a closure over it.
node-openid is not working with wordpress.
Debugged it, and found out the problem, but can't checkout and commit at the moment.
At line 358 in openid.js there is the Regular expression for the link-tag Wordpress is using.
The problem is wordpress uses ' instead of ". So the RegEx doesn't match and the lib fails to get the Information.
The Tags wordpress is sending are:
<link rel='openid.delegate' href='http://cleancoder.wordpress.com/' />
The RegEx has to be fixed, I think after that wordpress will work!
Thanks.
When using openid v0.1.2 on node.js v0.3.7 with Google's openid provider(https://www.google.com/accounts/o8/id) the request stays in endless loop.
Authenticating using "https://www.google.com/accounts/o8/id" as id throws:
ReferenceError: nextProvider is not defined
at node-openid/openid.js:728:13
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.