Closed arlaneenalra closed 10 years ago
Thanks again for the detailed bug report.
All errors from strong remoting should be caught and written to the response. This specific error should have a statusCode
400
.
The crash is related, but there's another underlying issue that's a problem. I'm seeing the same crash even when I have an access token in the as described by the api docs. Here's a script to reproduce what I'm seeing in a freshly created application as described above:
#!/bin/sh
# create user
curl -X POST -H 'Content-Type: application/json' -d '{"email":"test@a.com", "password":"1234"}' localhost:3000/api/users
# login
RAW_TOKEN=`curl -X POST -H 'Content-Type: application/json' -d '{"email":"test@a.com", "password":"1234"}' localhost:3000/api/users/login`
TOKEN=`echo $RAW_TOKEN | sed -e 's/.*"id": "\(.*\)", "ttl.*/\1/'`
echo
echo "Token: $TOKEN"
curl -X POST "localhost:3000/api/users/logout?access_token=$TOKEN"
And here's the crash log:
csalch@Chriss-MacBook-Air ~/bug-test $ npm start
> bug-test@0.0.0 start /Users/csalch/bug-test
> node app.js
StrongOps not configured to monitor. Please refer to http://docs.strongloop.com/strong-agent for usage.
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
Browse your REST API at http://0.0.0.0:3000/explorer
LoopBack server listening @ http://0.0.0.0:3000/
POST /api/users 200 350ms - 157b
POST /api/users/login 200 329ms - 152b
/Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/shared-method.js:83
throw new Error(name + ' is a required arg');
^
Error: access_token is a required arg
at /Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/shared-method.js:83:17
at Array.forEach (native)
at SharedMethod.invoke (/Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/shared-method.js:74:13)
at HttpContext.invoke (/Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/http-context.js:221:12)
at /Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:416:9
at execStack (/Users/csalch/bug-test/node_modules/loopback/node_modules/strong-remoting/lib/remote-objects.js:287:7)
at /Users/csalch/bug-test/node_modules/loopback/lib/application.js:177:13
at /Users/csalch/bug-test/node_modules/loopback/lib/models/acl.js:445:17
at /Users/csalch/bug-test/node_modules/loopback/lib/models/acl.js:408:19
at /Users/csalch/bug-test/node_modules/loopback/node_modules/async/lib/async.js:229:13
npm ERR! bug-test@0.0.0 start: `node app.js`
npm ERR! Exit status 8
npm ERR!
npm ERR! Failed at the bug-test@0.0.0 start script.
npm ERR! This is most likely a problem with the bug-test package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node app.js
npm ERR! You can get their info via:
npm ERR! npm owner ls bug-test
npm ERR! There is likely additional logging output above.
npm ERR! System Darwin 12.5.0
npm ERR! command "/usr/local/Cellar/node/0.10.24/bin/node" "/usr/local/bin/npm" "start"
npm ERR! cwd /Users/csalch/bug-test
npm ERR! node -v v0.10.24
npm ERR! npm -v 1.3.21
npm ERR! code ELIFECYCLE
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /Users/csalch/bug-test/npm-debug.log
npm ERR! not ok code 0
And the output from the script:
csalch@Chriss-MacBook-Air ~ $ ./test.sh
{
"password": "$2a$10$eIvT9M.iB/KBdk0jCiE1P.Maqi.N4iTiU.8ntL/o3lG9UMa6d35EG",
"email": "test@a.com",
"credentials": [],
"challenges": [],
"id": 1
} % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 193 100 152 100 41 456 123 --:--:-- --:--:-- --:--:-- 459
Token: yrsuBVX6xar52hgjjCxtN5u0CdkiKu78Mf5rlFYDSI3A6sFeAoalaSrNK3iBCtvC
curl: (52) Empty reply from server
I'm 99% sure the issue is that app.js
is missing the loopback.token
middleware. You can manually add this, and look for it to be added to the workspace (scaffolding) in the next version. This will require updating your version of slc
to include in new projects. Below is the expected order of middleware:
app.use(loopback.cookieParser('secret'));
app.use(loopback.token({model: app.models.accessToken}));
app.use(apiPath, loopback.rest());
app.use(app.router);
app.use(loopback.urlNotFound());
app.use(loopback.errorHandler());
app.enableAuth();
That looks like it was the underlying issue for me. I had seen the token middleware in the loopback but nothing on how it was used/configured.
Here is a link to the docs.
http://apidocs.strongloop.com/loopback/#loopbacktokenoptions
Thinking of the bigger picture, the fact that you have to read those docs is what I'd consider a "UX bug". One we can fix fairly easily by ensuring the correct middleware are included in the scaffolded app. Thanks for pointing this issue out. Look for a fix shortly.
I think this is the first time I've seen those docs. A cursory look over the site leads me to docs.strongloop.com but I can't find a link to apidocs.strongloop.com It would be really nice to have an intuitive means of finding them.
/to @crandmck, note doc site feedback at https://github.com/strongloop/loopback/issues/117#issuecomment-31409114
Fixed in loopback workspace 2.1.3 and strong remoting 1.1.6
Steps to reproduce:
slc lb project bug-test
npm start
orslc start
curl -X 'POST' localhost:3000/api/users/logout
I've seen this happen with and without an access token parameter.
Console output:
npm ls