extend range of status allowed/denied

[karlmikko]

see strongloop/loopback#301

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[bajtos]

Hi @karlmikko, thank you for the pull request.

I am little bit worried that if the tests treat all of 404,403,401 as the same code, then they may miss the case where the application was supposed to return 403 but returned 404 instead, because the route was not found. Thus a test "action should be denied" passes even though the action was not executed at all.

How about adding a global config option for specifying the "access denied" status code value?

helpers.accessDeniedStatusCode=401;_it.shouldBeAllowed=function(){it('should be allowed',function(){assert(this.req);assert(this.res);assert.notEqual(this.res.statusCode,helpers.accessDeniedStatusCode);});}_it.shouldBeDenied=function(){it('should not be allowed',function(){assert(this.res);varstatus=this.res.statusCode;assert.equals(status,helpers.accessDeniedStatusCode);});}

@ritch what's your opinion?

[bajtos]

On the second thought, it.shouldBeAllowed should check that the status code is a success, i.e. 2xx or 3xx. That way the test fails when the action failed due to server-side exception (5xx), when the access token is not valid (401), etc.

[karlmikko]

I will change to match that pattern

[bajtos]

Landed, thank you for the contribution.

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[ritch]

Nitpitck: < 400 would be a bit easier to read IMO

[bajtos]

Yes, that was my first thought too when I saw this code. This line is going to be changed by #15 anyway.