Skip to content
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.

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

Datasource projection is not respected for POST requests #1189

Closed
Kobzol opened this issue Sep 7, 2018 · 3 comments
Closed

Datasource projection is not respected for POST requests #1189

Kobzol opened this issue Sep 7, 2018 · 3 comments
Milestone

Comments

@Kobzol
Copy link

@Kobzol Kobzol commented Sep 7, 2018

Expected Behavior

When I specify a datasource with a projection on a domain, I expect that it would also be respected for inserting new items (POST requests).

I have an endpoint for users and I don't want to return one of their attributes (password) after a POST request that creates a new user. With bandwidth saver it wouldn't be returned, however I'm using BANDWIDTH_SAVER = False globally and thus Eve returns the attribute, even though it's not whitelisted in the datasource projection.

My scenario could be solved by allowing to set BANDWIDTH_SAVER per each endpoint individually, however I think that the datasource projection should be respected in POST requests.

BANDWIDTH_SAVER = False

'users': {
        'schema': user_schema,
        'resource_methods': ['GET', 'POST'],
        'authentication': AdminAuthenticator,
        'datasource': {
            'projection': {
                'username': 1
            }
        }
    }

POST /users returns { _id: ..., username: ..., password: ... }
GET /users doesn't return the password attribute (that is the correct behaviour)

Actual Behavior

The password field is returned after a POST request.

Environment

  • Python version: 3.6.5
  • Eve version: 0.8.1
@nicolaiarocci
Copy link
Member

@nicolaiarocci nicolaiarocci commented Oct 3, 2018

Yes, I agree, that would be ideal.

For the time being, you can probably circumvent the issue by resorting to a post-insert event hook in which you strip the password field before the response is returned to the client.

@nicolaiarocci nicolaiarocci added this to the 0.8.2 milestone Oct 3, 2018
@Kobzol
Copy link
Author

@Kobzol Kobzol commented Oct 3, 2018

Thanks, I resorted to that. If you could give me a pointer on where the datasource is applied, I could try to add this feature and send a PR.

@nicolaiarocci
Copy link
Member

@nicolaiarocci nicolaiarocci commented Mar 28, 2019

Should be fixed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants