I have an simple login-based application that serves different pages to different users. Problem im facing here is when two users are logging in at once from two different systems. if user A comes in and B loggs in then when A refreshes his/her page user A can see What user B can see. does flask app not handle two processes at a time?
or should i just use another server on this for the support.
or is there a way i can implement threading for this purpose.
i found uwsgi but i have no idea about it but can it serve my purpose in any way?
Please help me on this i have been working on this for a month now and i could not find a legit answer for this one.
Use sessions , have strong app secret key and have a database such as SQLAlchemy
Related
I am currently at the planning stage of an app that will consist of standard
Django part for supervisors that can perform all CRUD operations on employee users mostly add, delete and view statistics - viewed in browser (no frontend framework just using Djangos server side rendering), two step email authentication on each login, session based auth
DRF part for employees - API connected to mobile app, authentication based on device ID. (no username, or password)
DRF part for clients to contact the supervisors if employees do something wrong - Token or JWT based authentication using passcode delivered by mail.
I am not used to splitting Django projects into multiple sub-projects (or using same database for different projects) but it feels like every part of the project should be a standalone app due to different authentication type and the fact of simultaniousily using DRF with standard Django
Can anyone who had similar problem or has some experience, advise what should I do considering different authentications and overall different user types in this project? What would be pros and cons of going into solo or multiple projects? Thanks in advance!
You're asking for opinions, so don't be surprised if the question gets closed, but I'll answer with facts:
A split over different projects using the same database has the following issue: shared migrations. They all use built-in users, so require some standard apps to be enabled that have migrations and they won't run on the 2nd and 3rd project.
You're going to need a custom user model to support the device id authentication method: You need information that is not on the standard user model to be available at authentication time - the number 1 reason to create a custom user model. Ties into migrations and also a synchronization hell code-wise.
Django's Authentication Backends system allows for different authentication methods to exist at the same time, so there is no need to split anything. If you're worried about security, you can always use different hostnames and the Sites framework to add an extra layer of protection, but they would still use the same code.
DRF started as an addition to Django's view-based approach, not a replacement to make part of a project's code available as an API. While current usage is more "DRF or templates" this is a result of people increasingly becoming binary ("this" or "that") and wanting to be in the cool club, but has nothing to do with technical reasons. They can and always will be able to co-exist as they solve different problems. In fact, DRF's generic views make use of Django's CBV's and the built-in browsable API makes use of templates. Also, the admin is template/view based and it's convenient to develop the app or manage data with the built-in admin.
I am trying to get multiple sites to use the same database and code but in a way which forces each user to have their own login to each site.
I have seen a few suggestions as to how to make this work but I'm not sure which way to go.
I am using the Sites Framework, using the subdomain to identify the current site so I'm not using SITE_ID at all.
Use the sites framework - This answer (https://stackoverflow.com/a/1405902/1180442) suggests using the sites framework to do it, but I'm having trouble with the get_user() method, as it doesn't have access to the request and that's where my site info is stored.
Use separate databases for users - I'm really not sure about this one but I think it might cause bigger problems down the line.
Change to using SITE_ID - I want to try and avoid this if possible as it will mean having to run many different instances of my app, one for each site, which uses it's own settings.py. This will quickly turn into a nightmare, I think.
Permissions - I'm wondering if this should be something that I get the permissions framework to use? So one set of users for all sites but each user can have permissions to see each site, as long as they've registered with that site?
Can anyone help with this?
I quite like the idea of number 1 but I just need to get the request in the get_user() method so I can do this
def get_user(self, user_id):
try:
# I can't do this because there is no request available here
return User.objects.get(pk=user_id, site=request.site)
except User.DoesNotExist:
return None
to prevent people logged in to one site being able to log into another using the same session.
How I actually do it, not for users but for common databases, Is to design a main, hidden app with a REST API architecture. My other apps, naturally have their own DB and exchange their data via batch or stream process depending on the need. I use django-rest-framework.
For your case what I would do is that whenever a user makes a Log In request I would send it via HTTPS to my main database and get it authenticated in my main app. Whenever I would need to validate the user status I would simply make a get request to the main app.
This architecture is not that different from the one that many mobile apps have.
I hope it helps.
I was wondering whether it is possible to have more than one user log in on a development server using Django 1.8
I am creating an app, where these "active" users are able to view one another details (or fields) respective to the relative models I designed.
Currently, I am only able to log in as a single user and wondered whether it is possible to somehow allow my app to have multiple logins.
Thanks
The easiest way is to use multiple browsers, and if necessary, multiple dev servers on alternate ports. 8000, 8001, etc.
I would like to have one users system (preferrably Django's) to rule both Django and Wordpress.
The use case is that Django is an application embedded inside a wordpress installation (via iframe or something similar). In order to use the Django, users must be authenticated, authentication in WordPress is not mandatory, but recommended (for posting comments and stuff like that).
In order to ease the usage of the site, I would like the same sign-up to apply for both the Django app and the WordPress installation. Sign-up might occur either via OAuth / FB authentication (lots of Django solutions for this), or via dedicated site users. While the signup process is most important, it would be nice if certain user fields would remain synced between the two worlds.
My thoughts on the matter:
Maybe there's an out-of-the-box solution (couldn't find any)
Create a full-fledged django app for syncing the two user models (wp_users and django's users) via one of the following options:
A master(django)-slave(wp) solution, where each change in Django changes info in the wp_users and other related tables and vice-versa (via Django periodically checking the DB or creating a WP plugin). Can be implemented either by putting both django and wp on the same (MySQL) db, using XML-RPC or some other anomination I didn't think of.
Same as above, but let WP be the master instead of Django (seems harder).
An external system to rule both models - maybe make OAuth / some other external authentication mandatory, and somehow sync the two models using this?
Has anyone encountered this situation before?
Any suggestions will be appreciated.
You should really try to work out some approach, revising your work when encountering problems afterwards.
Nevertheless imo Wordpress is kind of bordered. I wouldn't recommend making changes to both frameworks, but fixate on Django.
For example you could create a WordpressUser(User) and create a python script a crobjob, celery task or whatever you'll need to syncronize your databases. Meaning to say you should keep things strictly separated unless you have very good reasons not to (I can't think of any).
I have a medium sized Drupal 6 site running (around 5 million page views per month and more than 30K registered users) and I need to integrate OSQA, a Django application, with it. I already have many users, roles and permissions in my Drupal database and I'd like to point the Django app to use the sign up and login pages I already have in Drupal to give my users a single point on entrance.
I want to keep the Django authentication part because I think OSQA would work better. I also have performance reasons in mind, the Drupal site already gets a lot of traffic and has a very busy database and I think that using a separate database for Django would help.
After some research I think I could make the Drupal sign up and login pages call Django in the background to sign up or login to the Django app. I plan to do this writing a couple of views in Django, one for sign up and another for login, and Drupal would post the username and password to those views. Of course I'd need to disable CSRF in Django for those views and probably also post some secret key that only my Drupal and Django applications know about to avoid external sites trying to use this "unprotected" Django views.
I know that my Django application may need some user data from Drupal at some points and I'm planning on using the Drupal services module for that.
Would this be a good approach? Any suggestions?
Thanks a lot!
Are there any plugins for OSQA to expose an authentication service that Drupal can talk to? (OpenID or similar).
Alternatively, check out Drupal's ldap_integration module for an example of a module that uses an external authentication service. Consider that you will need to create Drupal user accounts for each login.
Finally, why not just build the essential parts of OSQA's functionality with Drupal? Seems like the key functionality could be replicated quite easily using Taxonomy, Vote Up and Userpoints/User Badges... potentially easier to do than shared authentication, especially on a large site.
I once created a very simple [sql_authentication][1] module, which you can probably simply re-create for a more recent version of Drupal.
The idea is simple: provide Drupal with an alternative authentication callback.
In that callback-function, just check against the Django database, and return TRUE if you think the user is correct.
You could look at how openid.module (in core) extends the user-authentication for a simple example.
If you can post to the Django form, you may be able to use drupal_http_request to handle the call to Django. After using the ldap_integration module for a while, I worked on a custom authentication module that calls a Java-based REST authentication API using drupal_http_request. If you're interested in the code, let me know.