I am developing a web application using flask, Werkzeug and jinja2. I am very much confused with these terms and wanted to know the meaning of the terms and how they are interrelated to the CGI environment variables. What is global variable g and how it is related to the application context and request context.
Also since I don't have much knowledge of developing web apps( I am doing it for first time) any another language also so there is another request if someone could give a reference or make me understand that how the requests are handled, i mean what happens when a request arrives to the web application.
Also if i am not using any openID providers for logging in the user into my website, how can I make the password secure. Should I use any framework for that?
For request context better look next question: What is the purpose of Flask's context stacks?. Better spend a little time to understand it because it basic framework principal.
Many approaches for user data storing will be secure, the easiest store user in database and password as modern_crypto_hash(password + salt) with limitation for short passwords acceptance and use something for logging as Flask-Login or Flask-Principal. To avoid SQL injections you can use any ORM, for example SqlAlchemy. To avoid XSS send data changing by POST and add csrf token, WTForms good there. To avoid html tags injection already use build in template system by default and do not insert user content to page unsafely. Also can be useful https.
Related
I was using Flask for a small personal project of mine, and using render template and simple HTML files for the front-end.
I recently decided to switch over to a react front-end with a REST API in Flask.
However, since a lot of my old flask code depended on using sessions within Flask, I was wondering if sessions can still be used with a REST API.
There are essentially two parts to the question:
Is it technically correct (i.e. would it even work)
Is it advisable (If no, why not)
Thanks
Yes you can use sessions for login for a front end API. For backend APIs I suppose you could as well but something like jwt or oauth2 is much more common for a few convenience reasons. Not sure the set cookie header works when called via the JS fetch api so you may need to create your own session cookie with JS and possibly in middleware. You also have the option of having the login page not part of the API which would solve this problem.
Other than that as long as the session cookie is being passed to the API every time it is called which should happen automatically you will be able to use sessions in your Flask code.
What is the best way to do user management in a single page JS (Mithril) app? I want users to login to load preferences and take on a role so they gain certain permissions. I have a REST API backend written in Python (Falcon web framework). Having read a bit into it, it seems to boil down to sending credentials to the backend and get a token back. But the question is how that should be done. It seems that tokens are a better method than cookies, but that has effects on the exchange of secrets/tokens. the 'xhr.withCredentials' method seems to be cookie based for instance. JWT (json web tokens) seems like a modern, interesting option, but it's hard to find a clear explanation how it could be used with a SPA.. And once the Mithril app has a token, where should I store it and how should I use it with subsequent requests?
This isn't so much about Mithril, actually the only Mithril-related area is the server communication. That is done with the m.request method (docs here), but you need to create an object for all server communication that requires authentication.
That object should have knowledge about the auth system and detect if a token expired, then request a new one, take proper action if things fail, etc. It's a bit of work, but the process is different for most auth systems, so there's not much to do about it, except using something that already exists.
Being a small and lean MVC framework, Mithril doesn't have any security-related features built-in, but the m.request method is very powerful and you should use that inside the auth communication object.
The client-side storage will be in cookies or HTML5 storage. Here's an StackExchange answer that goes into more depth: https://security.stackexchange.com/a/80767 but the point is that this isn't Mithril-related either.
Thanks for linking to the tokens vs. cookies article, it was very nice!
I am developing a back-end for a webpage using Django Rest Framework. The webpage will be public, and it will only fetch information from this service. Thus, I have to deploy both service and webpage.
Since the webpage is public access (without any type of login) I can avoid having to set up the SSL stuff. However, by default, the DRF comes with the browsable API and the login field. I know I can remove the browsable API, but is it enough?
For instance, the configurations I would have would be:
(removing the BrowsableAPIRenderer)
'DEFAULT_RENDERER_CLASSES': ( 'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.JSONPRenderer',
'rest_framework_csv.renderers.CSVRenderer', )
and:
CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOW_METHODS = (
'GET',
'HEAD',
'OPTIONS',
)
I am using https://github.com/ottoyiu/django-cors-headers for the CORS stuff.
Would this be enough to avoid unwanted login atempts? Is there any specific way to disable this option?
What 'DEFAULT_PERMISSION_CLASSES' shoul I use?
Best regards and thanks for any help!
If you have a login, but you don't have SSL, then your users are vulnerable to packet sniffing of credentials on many wifi and ethernet networks. Such a vulnerability can be trivially exploited with the Firesheep firefox plugin. Due to users' habit of reusing passwords, you could end up compromising their security to a more critical website. This is very unfortunate. It isn't entirely your problem if users reuse their password, but SSL should be a base layer of protection to your users.
While it is possible to use Django templates with Django Rest Framework (DRF) as the backend, you are not limited to using Django for your front-end. Consider AngularJS with DRF. Anyways, there is a significant learning curve for AngularJS, but you needn't limit yourself to having Django supply your front-end.
As far as removing the DRF BrowsableAPIRenderer, you will get some protection from "security through obscurity", but you really need to lock down your APIs through a proper permission model as an attacker can easily look at traffic generated by your front-end to your back-end and then manipulate the requests to your back-end. So, discoverability of your interface by an adversary will not be significantly reduced through getting rid of BrowsableAPIRenderer. It will only obscure back-end resources that your front-end isn't currently using and it will also make your life as a front-end dev a little more painful.
For DEFAULT_PERMISSION_CLASSES, take a gander at DRF permissions documentation. If you only have two user groups - logged in/authenticate and not logged in, then IsAuthenticatedOrReadOnly is a good place to start. If you start to have per-model permission bifurcation for different user groups, then
DjangoModelPermissions is a good place to dig into.
I'm building a little application in Python. I use PySide for the GUI and Django to read data from my web application.
Everything works well, but I have a login access, like dropbox application.
I want to store this informations on the current machine (like a session, I don't want to login every time I open the application).
Now my question is, what is the safest way to do this? Environment variables?
Usually when you have an API that you're exposing in your app to the outer world (even your own desktop/mobile app), you'll design this API to be stateless, as part of the REST architecture. So your app should always include an HTTP header or any other method of carrying an authentication token that will let your API identify the user.
You only log in once, and when the log-in procedure is successful you should get an authentication token from your API, and then you will store this token somewhere safe.
You can also look into implementing OAuth2 for the authentication.
I have been reading at multiple places and it is suggested that the Web Servers should be Stateles with share nothing architecture. This helps them scale better.
That means each request has all the information needed to process the request.
This becomes tricky when you have REST endpoints that needs authentication.
I have been looking at ways Flask extensions do this and Flask Login extension is defined as
Flask-Login provides user session management for Flask. It handles the
common tasks of logging in, logging out, and remembering your users’
sessions over extended periods of time.
This seems like against the philosophy of building a Stateless server, isn't it?
What are better ways to build a Stateless server with authentication provided via HTTP headers with Python or related python libraries?
P.S: Apologies for not posting a programming question here, this is a design issue and I do not know how to solve it and SO seems to have right people to answer such questions. Thanks.
Flask-Login uses flask's built in session management, which by default uses secure/signed cookies, and so is purely client side.
It can support server side sessions if needed though of course, here's an example redis backed session store.
I've the same problem as you have said.
While I have built a simple solution for this but looking for a better one.
What I currently did is to ask the caller (Who send the http request) provide a 'X-User-Info' in the http header, the value is a token. When I received the request, I use this token to get user identity (From redis for instance) and all of the following authorization & permission control are based on this identity.
The authentication does nothing but generate a random token, save it with user info to redis and return the token itself to the caller.