In my project we are trying to create micro service type architecture using djnago/django-rest-framework.
We've some services like:
User management service
Asset Management Service
Tool management service
All three services running on different Ports with different database.
Now my question is,
Can we use user management service in Asset and tools service for Token authentication?
This is quite a broad question and without knowing more of your specific architecture, what you have tried and what features you want/need, it will be hard to give anything more than a starting point.
That being said, you could look at setting up a Central Authentication Service. (CAS) There's multiple packages for Django that help you with this.
Try looking into Django CAS NG and Django MamaCAS. Django CAS NG seems to be the more actively developed of the two.
Remember that with microservices, one of the big advantages is that there's nothing forcing you to use the same technology across your entire stack. It may well make sense to have your auth components provided by something entirely different, for example rolling a KeyCloak server to handle SSO.
Related
I want to programmatically create a principal with a calendar for every user of my web site. There is lots of documentation on how to create calendars, but I have a hard time finding anything on creating principals.
Any hint is appreciated, preferred language is python, but docs for other languages could help me as well.
Thank you for your help!
WebDAV ACL does not provide a way to manage principals. And I'm not aware of any draft/RFC adding that feature.
In short: You can't manage principals using WebDAV and how principals are backed is highly server specific.
Some servers may use the LDAP standard to manage their accounts, for example the CalDAV server which is part of macOS X Server does.
If the LDAP server is configured to allow that (which often is not the case), you may be able to create accounts using that protocol. I'm sure there are Python libraries providing access to LDAP.
Other servers often provide proprietary protocols or tools to create accounts.
I've published an iOS app using a local database stored directly on the user's device. What I'd like to do for my next app is have a central database on a remote server where users can asynchronously send/receive data. I'm relatively new to web service programming and I'm not sure where to start. I've purchased a server space on a web hosting site and have a MySql database/phpMyAdmin configuration on the server. I'm not sure how to handle the server side code. I know well enough that a database should never be exposed publicly over the internet for obvious security reasons. Therefore I need some kind of web service where my iOS/Android apps can query the service, the web service fetches data and sends it back to the clients in a XML or JSON format. I'd like to write the web service layer in python. I've done a little research and django seems to be recommended by some for these kinds of things. So, my questions are:
What are good resources for making a web service in python on a remote server.
What are the "best practices" for creating/debugging/testing the server side code. Should I try and make a local MySql database and write the server code locally and test and then push it to my remote server when it is finished?
My ultimate starting goal is some kind of proof of concept hello world app. Where from my iOS and android devices I can query the remote database going through the service layer and getting data back or inserting data.
Any tips or advise would be appreciated. I'm a noob in this area but ready to learn.
Too many general questions in one, so I'll just refer you.
I'd start with an awesome Designing Poetic APIs PyCon US 2014 talk.
Since you want to follow the REST principles with Django, take a look at the list of django packages available for writing RESTful apps: Applications that help you build a REST API.
Basically, the major "players" are:
django-tastypie
django-rest-framework
Also see:
What are the differences between django-tastypie and djangorestframework?
Choosing an API framework for Django
Hope that helps.
Currently I am working on a portal which is exposed to end users. This portal is developed using Python 2.7, Django 1.6 and MySQL.
Now we want to expose this portal as a mobile app. But current design does not support that as templates, views and database are tightly coupled with each other. So we decided to re-architect the whole portal. After some research I found following:
Client side: AngularJS for all client side operations like show data and get data using ajax.
Server side: Rest API exposed to AngularJS. This Rest API can be developed using either Tastypie or Django Rest Framework (still not decided). Rest API will be exposed over Django.
I have few questions:
What you guys think about architecture? Is this is a good or bad design? How it can be improved?
Will performance of portal will go down after adding above layers in architecture?
In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.
Currently portal is getting 10K hits in a day and it is expected to go to 100K a day in 6 months. Will be happy to provide more information if needed.
If i got an opportunity to architect the portal which you mentioned than i would really love to design the architecture which i have already explained here.
What you guys think about architecture?
This is a common Service Oriented Architecture with decoupled Clients. You just have REST endpoints on your backend, and any Client can consume those endpoints.
You should also think about:
Do you need RESTful service (RESTful == stateless, will you store any state on the server?)
How to scale the service in the future? (this is a legit thing as you already aware of huge traffic increase and assume 2 servers)
How it can be improved?
Use scala instead of python :)
Will performance of portal will go down after adding above layers in architecture?
It depends.
It will get some performance penalty (any additional abtract layer has it's tax), but most probably you won't event notice it. But still, you should measure it using some stress tests.
In the above architecture whether 2 servers should be used to run this (like one for client and other for serving the API's) or one server will be enough. Currently Heroku is used for deployment.
Well, as usual, it depends.
It depends on the usage profile you have right now and on the resources available.
If you are interested in whether the new design will perform better than the old one? - there are a number of parameters.
Resume
This is a good overall approach for the system with different clients.
It will allow you:
Totally decouple mobile app and frontend development from backend development. (It could be different independent teams, outsourceable)
Standardize your API layer (as all clients will consume the same endpoints)
Make you service scalable easier (this includes the separate webserver for static assets and many more).
Here is the situation:
We use Flask for a website application development.Also on the website sever, we host a RESTful service. And we use Flask-login for as the authentication tool, for BOTH the web application access and the RESTful service (access the Restful service from browsers).
Later, we find that we need to, also, access the RESTful from client calls (python), so NO session and cookies etc. This gives us a headache regarding the current authentication of the RESTful service.
On the web, there exist whole bunch of ways to secure the RESTful service from client calls. But it seems no easy way for them to live together with our current Flask-login tool, such that we do not need to change our web application a lot.
So here are the question:
Is there a easy way(framework) so the RESTful services can support multiple authentication methods(protocols) at the same time. Is this even a good practice?
Many thanks!
So, you've officially bumped into one of the most difficult questions in modern web development (in my humble opinion): web authentication.
Here's the theory behind it (I'll answer your question in a moment).
When you're building complicated apps with more than a few users, particularly if you're building apps that have both a website AND an API service, you're always going to bump into authentication issues no matter what you're doing.
The ideal way to solve these problems is to have an independent auth service on your network. Some sort of internal API that EXCLUSIVELY handles user creation, editing, and deletion. There are a number of benefits to doing this:
You have a single authentication source that all of your application components can use: your website can use it to log people in behind the scenes, your API service can use it to authenticate API requests, etc.
You have a single service which can smartly managing user caching -- it's pretty dangerous to implement user caching all over the place (which is what typically happens when you're dealing with multiple authentication methods: you might cache users for the API service, but fail to cache them with the website, stuff like this causes problems).
You have a single service which can be scaled INDEPENDENTLY of your other components. Think about it this way: what piece of application data is accessed more than any other? In most applications, it's the user data. For every request user data will be needed, and this puts a strain on your database / cache / whatever you're doing. Having a single service which manages users makes it a lot nicer for you to scale this part of the application stack easily.
Overall, authentication is really hard.
For the past two years I've been the CTO at OpenCNAM, and we had the same issue (a website and API service). For us to handle authentication properly, we ended up building an internal authentication service like described above, then using Flask-Login to handle authenticating users via the website, and a custom method to authenticate users via the API (just an HTTP call to our auth service).
This worked really well for us, and allowed us to scale from thousands of requests to billions (by isolating each component in our stack, and focusing on user auth as a separate service).
Now, I wouldn't recommend this for apps that are very simple, or apps that don't have many users, because it's more hassle than it's worth.
If you're looking for a third party solution, Stormpath looks pretty promising (just google it).
Anyhow, hope that helps! Good luck.
I am working on a Python App, which runs on App Engine. Is there a way I can publish the app on each customers' appSpot account, so that the App uses the users' cloud storage? Instead of running the App on my AppSpot account and all the users storing the data on my Cloud space?
Yes, absolutely.
You just need to have each client create an App Engine account with an application to which you have administrator access. You can adjust the settings on the application to forbid downloads of your code by the other administrators if that's appropriate for your agreement with the client. This also allows the clients to be billed directly for their instances' usage, and makes it completely impossible for data to leak between different clients' instances.
Using multiple applications for multiple clients who are licensing your application almost certainly does not violate part 4.4 of the TOS, although don't take this as legal advice.
No, you cannot do that. The app is hosted and run in the administrator's account which would be you. What you can do is, release the source code and point your users do install it in their appspot account, just like creating a new application.
I suppose it's not exactly what you need. But it can give you an idea where to go. Please check DryDrop project. There is small Python application you can ask each user to install on their account, then they can configure it to fetch your site files from your GitHub repo through webhooks functionality. I didn't try it, but, theoretically, you update your site, commit it to your repo, and all users get your updated application automatically. You can share your thoughts if that works for you.
Maybe. If it's an open source app that you're giving away, you can publish the source and instruct users to upload it to their own accounts.
If you're selling the app, displaying ads or otherwise trying to monetize the service, you probably want to stick with one instance. Using multiple instances to avoid paying for quota usage is direct violation of the App Engine TOS:
4.4. You may not develop multiple Applications to simulate or act as a
single Application or otherwise access
the Service in a manner intended to
avoid incurring fees.
No. Writing an application that deploys other applications is in violation of the terms of service.
Note we don't have any 'hard' limits - those limits that aren't billing enabled can be increased on application to us if you provide a reasonable use-case.