Skip to content

[Erlang-Server] security definition context changes don't propagate to handler #5751

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 30, 2020
Merged

[Erlang-Server] security definition context changes don't propagate to handler #5751

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
77198b4
Map Merge Context & Params
ehansen31 Mar 29, 2020
a746cfc
post build & shell script
ehansen31 Mar 29, 2020
61c07d8
Delete VERSION
ehansen31 Mar 30, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion modules/openapi-generator/src/main/resources/erlang-server/handler.mustache
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -225,7 +225,7 @@ handle_request_json(
LogicHandler,
OperationID,
Req1,
Populated
maps:merge(State#state.context, Populated)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm. Shouldn't this be merge in the reverse order in order to keep the request specific values?

Suggested change
maps:merge(State#state.context, Populated)
maps:merge(Populated, State#state.context)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://erlang.org/doc/man/maps.html#merge-2

I was shooting for backwards compatibility, in such that a user is used to having only the parameters input into context. this change wouldn't overwrite any user input parameters and preserve any functionality where a user may accidentally overwrite with the addition of the context being passed from security definitions. So your suggestion would place user parameters in the context, then overwrite with the security definitions. Makes sense from a data transformation POV. I'll make the change later today.

),
_ = {{packageName}}_api:validate_response(
OperationID,
Expand Down
1 change: 0 additions & 1 deletion samples/server/petstore/erlang-server/.openapi-generator/VERSION
View file
Open in desktop

This file was deleted.

2 changes: 1 addition & 1 deletion samples/server/petstore/erlang-server/src/openapi_pet_handler.erl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -456,7 +456,7 @@ handle_request_json(
LogicHandler,
OperationID,
Req1,
Populated
maps:merge(State#state.context, Populated)
),
_ = openapi_api:validate_response(
OperationID,
Expand Down
2 changes: 1 addition & 1 deletion samples/server/petstore/erlang-server/src/openapi_store_handler.erl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -251,7 +251,7 @@ handle_request_json(
LogicHandler,
OperationID,
Req1,
Populated
maps:merge(State#state.context, Populated)
),
_ = openapi_api:validate_response(
OperationID,
Expand Down
2 changes: 1 addition & 1 deletion samples/server/petstore/erlang-server/src/openapi_user_handler.erl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -304,7 +304,7 @@ handle_request_json(
LogicHandler,
OperationID,
Req1,
Populated
maps:merge(State#state.context, Populated)
),
_ = openapi_api:validate_response(
OperationID,
Expand Down