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

Secure the backend #42

Open
1 of 2 tasks
dahoo opened this issue Nov 24, 2015 · 5 comments
Open
1 of 2 tasks

Secure the backend #42

dahoo opened this issue Nov 24, 2015 · 5 comments

Comments

@dahoo
Copy link
Member

dahoo commented Nov 24, 2015

  • Disable the API post form in prodution. People shouldn't be allowed to add new data without the frontend.
  • How to prevent everybody from seeing user data, e.g. email adresses?
@illing2005
Copy link
Member

  1. Can by solved by adding

    REST_FRAMEWORK = {
    'DEFAULT_RENDERER_CLASSES': (
        'rest_framework.renderers.JSONRenderer',
    )
    }
    

    to the poduction settings.
    But I like the BrowsableAPIRenderer, because it's easier to debug.

  2. Do we need email addresses in the frontend? I would just remove them from the UserSerializer

@dahoo
Copy link
Member Author

dahoo commented Nov 25, 2015

  1. Okay, but it would suffice to have it in the development environment, right?
  2. Yes, for example if the user wants to change it. But there must be some best practices for that...

@hrantzsch
Copy link
Contributor

  1. People are already only allowed to post data when they are logged in. What does it matter if they use a frontend for that?
  2. api/users should generally not be available. No frontend needs to access the data of all users, right? We should only offer data for the user who is logged in.

@dahoo
Copy link
Member Author

dahoo commented Nov 25, 2015

  1. Great, I wasn't aware of that.
  2. There's no need for to request all users, but we need to query the name of a certain user. But true, the email adress doesn't need to be included.

@hrantzsch
Copy link
Contributor

You mean when viewing a request or offer, right? Then we really only need to provide a way to resolve the name of the user who belongs to the request/offer.

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

No branches or pull requests

3 participants