Skip to content
This repository has been archived by the owner on Aug 19, 2022. It is now read-only.

Bug: 500 server error when creating a policy #475

Closed
ShaunBaker opened this issue Feb 23, 2018 · 5 comments
Closed

Bug: 500 server error when creating a policy #475

ShaunBaker opened this issue Feb 23, 2018 · 5 comments

Comments

@ShaunBaker
Copy link

The following request:

curl 'http://localhost:8810/authorization/policies?sig=serviceKey' -H 'Pragma: no-cache' -H 'Origin: http://localhost:3001' -H 'Accept-Encoding: gzip, deflate, br' -H 'Accept-Language: en-GB,en;q=0.9,en-US;q=0.8,ru;q=0.7' -H 'Content-Type: application/json;charset=UTF-8' -H 'Accept: application/json, text/plain, */*' -H 'Cache-Control: no-cache' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36' -H 'Connection: keep-alive' -H 'Referer: http://localhost:3001/policies' --data-binary '{"name":"Test Policy 1","version":"1","statements":{"Statement":[{"Effect":"string","Action":["string"],"Resource":["string"],"Sid":"string","Condition":{}}]}}' --compressed

Produces the following response:

{"statusCode":500,"error":"Internal Server Error","message":"An internal server error occurred"}

Internally the logs are showing:

Debug: internal, implementation, error
    Error: child "PolicyStatements" fails because [child "Statement" fails because ["Statement" at position 0 fails because [child "Effect" fails because ["Effect" must be one of [Allow, Deny]]]]]
    at postValidate (/app/node_modules/hapi/lib/validation.js:212:30)
    at internals.Object._validateWithOptions (/app/node_modules/udaru/node_modules/joi/lib/types/any/index.js:654:20)
    at module.exports.internals.Any.root.validate (/app/node_modules/hapi/node_modules/joi/lib/index.js:139:23)
    at exports.response (/app/node_modules/hapi/lib/validation.js:242:20)
    at each (/app/node_modules/hapi/lib/request.js:401:16)
    at iterate (/app/node_modules/items/lib/index.js:36:13)
    at done (/app/node_modules/items/lib/index.js:28:25)
    at Hoek.once (/app/node_modules/hapi/lib/protect.js:50:16)
    at wrapped (/app/node_modules/hoek/lib/index.js:879:20)
    at done (/app/node_modules/items/lib/index.js:31:25)
    at finalize (/app/node_modules/hapi/lib/request.js:446:24)
    at Function.wrapped (/app/node_modules/hoek/lib/index.js:879:20)
    at Function.internals.continue (/app/node_modules/hapi/lib/reply.js:139:10)
    at bound (domain.js:303:14)
    at Function.runBound [as continue] (domain.js:314:12)
    at plugin.ext (/app/node_modules/hapi-swagger/lib/index.js:290:30)
    at each (/app/node_modules/hapi/lib/request.js:453:22)
    at iterate (/app/node_modules/items/lib/index.js:36:13)
    at Object.exports.serial (/app/node_modules/items/lib/index.js:39:9)
    at _protect.run (/app/node_modules/hapi/lib/request.js:456:15)
    at module.exports.internals.Protect.internals.Protect.run (/app/node_modules/hapi/lib/protect.js:60:12)
    at internals.Request._invoke (/app/node_modules/hapi/lib/request.js:436:19)

This should not be a 500 error - but a 400 Bad Request which communicates the error.

@ShaunBaker
Copy link
Author

As a followup to this - the policy has been saved - which is then causing the /authorization/policies endpoint to error with a 500:

Debug: internal, implementation, error
    Error: child "Data" fails because ["Data" at position 11 fails because [child "PolicyStatements" fails because [child "Statement" fails because ["Statement" at position 0 fails because [child "Effect" fails because ["Effect" must be one of [Allow, Deny]]]]]]]
    at postValidate (/app/node_modules/hapi/lib/validation.js:212:30)
    at internals.Object._validateWithOptions (/app/node_modules/udaru/node_modules/joi/lib/types/any/index.js:654:20)
    at module.exports.internals.Any.root.validate (/app/node_modules/hapi/node_modules/joi/lib/index.js:139:23)
    at exports.response (/app/node_modules/hapi/lib/validation.js:242:20)
    at each (/app/node_modules/hapi/lib/request.js:401:16)
    at iterate (/app/node_modules/items/lib/index.js:36:13)
    at done (/app/node_modules/items/lib/index.js:28:25)
    at Hoek.once (/app/node_modules/hapi/lib/protect.js:50:16)
    at wrapped (/app/node_modules/hoek/lib/index.js:879:20)
    at done (/app/node_modules/items/lib/index.js:31:25)
    at finalize (/app/node_modules/hapi/lib/request.js:446:24)
    at Function.wrapped (/app/node_modules/hoek/lib/index.js:879:20)
    at Function.internals.continue (/app/node_modules/hapi/lib/reply.js:139:10)
    at bound (domain.js:303:14)
    at Function.runBound [as continue] (domain.js:314:12)
    at plugin.ext (/app/node_modules/hapi-swagger/lib/index.js:290:30)
    at each (/app/node_modules/hapi/lib/request.js:453:22)
    at iterate (/app/node_modules/items/lib/index.js:36:13)
    at Object.exports.serial (/app/node_modules/items/lib/index.js:39:9)
    at _protect.run (/app/node_modules/hapi/lib/request.js:456:15)
    at module.exports.internals.Protect.internals.Protect.run (/app/node_modules/hapi/lib/protect.js:60:12)
    at internals.Request._invoke (/app/node_modules/hapi/lib/request.js:436:19)

@cianfoley-nearform
Copy link
Contributor

cianfoley-nearform commented Feb 23, 2018

Hi Shaun,

I found this bug, essentially our Joi statement object isn't limiting effect to allow|deny on input, however it is on output rule...

The error occurred on response validation, which does have the limitation, both the post and the get perform validation on the response and that's why the error is showing in both situations above...

Once the validation rule is in, this will become a 400 error.

@cianfoley-nearform
Copy link
Contributor

I'm currently updating all of our Joi validation objects with labels so the swagger doc becomes more consistent so I'll check this in with the rest of those fixes today

@cianfoley-nearform
Copy link
Contributor

here is the output after retesting with rules in place...

{
"statusCode": 400,
"error": "Bad Request",
"message": "child "StatementsObject" fails because [child "StatementsArray" fails because ["StatementsArray" at position 0 fails because [child "Effect" fails because ["Effect" must be one of [Allow, Deny]]]]]",
"validation": {
"source": "payload",
"keys": [
"statements.Statement.0.Effect"
]
}
}

@cianfoley-nearform
Copy link
Contributor

Fixed in this commit: 534787f

Will be included in next release...

dberesford added a commit that referenced this issue Mar 16, 2018
* Split code into 4 packages using lerna.

* Reconsiled master merge out to wprl:lerna-ize (#439)

* feat: get user teams, no inheritance

* fix: get user teams functionality, tests

* chore: changes feedback review

* chore: release 3.1.0 preps

* fix: allow empty results when the user is in no teams

* volume data insertion and autocannon bench tests

* database migration to 6, added index to team_members, fixed bug in volumeRunner starting server

* updated NUM_TEAMs in config to 500

* Forking child process for UDARU server in volumeRunner

* tidy ups and upgraded lodash to 4.17.5

* added chalk to volume load/test, using IPC when forking server, updated changes.md

* updated intermittently failing user policies test cases

* updated pbac version, iam.js also changed as the param order is important and needed to be reversed

* support for optional metadata field, team, user, org read only

* get, post and put updated for optional metadata field

* test cases on core added for create, update, read

* #450 solved: authorization pre-check required on teams payload object

* version 3.2.0 not 3.2.1

* updates to validatation models for better swagger definitions, enforcement of allow/deny on policies

* added test for issue #475 (invalid effect data)

* added a note to pagedteamslist to state policies and users not populated

* updates to all entities to throw 409 conflict instead of 400 for db insert/update conflict constraints

* fix migrate 7 uninstall script

* pre-merge issues addressed

* fix: add request id for the resource builder

* chore: bump package, update changes

* update to changes.md summary for 4.0.0

* chore: package lock update

* removing public schema from migration scripts

* updated version number in package.json and added 4.0.1 entry to changes

* support search teams in udaru core

* search team endpoint and search logic updates

* add total to team search response

* update search response validation to match actual response data

* Nested Teams Endpoint (#477)

* add nested teams to udaru core

* add nested endpoint

* add e2e test for nested team limit

* updating version and changes.md, updated pbac to 0.3.0

* use the buildParams directly to create base resource for user requests

* return 404 if nested team is not found

* Reset version to 4.0.1, it had accidently been set to 4.2.0

* check if team exists before returning users, check if user exist before return teams

* fix typo

* Example extended to demonstrate teams (#483)

* Support in udaru core for searching users (#463)

* Support in udaru core for searching users

* Linting fix

* Added some sanity check sql injection tests

* Linting fix (again)

* Linting fix (again again)

* expose public user search route

* add search users in a team

* Updated end to end testing for teams search and team users search

* updated version and changes

* updated changes.md 4.1.0 date

* Migration to nearForm SQL module

* Removed postgrator

* Removed postgrator

* Split code into 4 packages using lerna.

* packages/udaru/ -> packages/udaru-core/

* update version in changes.md, packages and static swagger docs
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants