I am in the middle of building a PhoneGap (Cordova) app which I would like to be able to talk to a Django site of mine. The steps needed to get the app working are:
Authenticate the user (stay logged-in across app restarts) (e.g. get session cookie from Django for communication with the service - where to store?). Note: The Django endpoint uses https.
When app receives push notification load some data from my django site.
Make selection on data and submit response back to my django site (will need the csrf token?)
I was able to sort out the push notifications but now I am wondering which solution would work best for the communication with Django.
As I understand there are two possible approaches:
Either to implement a REST service with something like tastypie or
try to setup the communication via ajax (e.g. jQuery)
At the moment I am thinking that going simply ajax might be the best approach since the app is fairly small and there are no additional requirement for a REST API.
It would be great if anyone could give me any pointers on how to solve this or share some experiece / code. Especially the steps of the authentication process are unclear to me.
I am not sure if this is still an open question but it is sure an interesting one.
I would strongly suggest on using the django-tastypie and you could start by using the docs which are indeed a great point of reference.
My experience until now has shown that I should always start by making my api clear(and rest) than choosing an easier faster solution(e.g. ajax) because if your app is a successful one, frameworks like tastypie help you scale.
The authentication process is pretty straightforward if you choose the basic one.
You just ask for the user credentials and there are many clients implementing the client side basic auth.
Fortunately, tastypie supports more than this. For example, the api authentication and you could read more here.
If you need anything else, please let me know.
Regards,
Michael.
Related
I'm currently studying computing and it tackles about API. I keep reading this term 'APIs provide an interface for communicating software' but i'm not really sure what is an interface to API? May i ask for your help to explain it?
Not sure if i get your question right, but let me have a try:
So basically a simple architecture of building for example an app is splitting it up in front- and backend. For example, in a ToDo-List app there is a server-side software which manages all data and we have a Mobile App which shows the data to the user. The backend is an "abstract" program. I mean with that that you can't click buttons or something else. So, when you want to create a task in your frontend app you have to tell the backend (for example written in Java or Python) that you want to make this. For this you can use an API.
This is basically an Call of an Website. The backend recognizes is and loads data out of an database, manages it and displays it for example in JSON Format. This format is send to the website.
Look here: https://jsonplaceholder.typicode.com/todos/1
The app now is able to automatically get this data and manages it.
Obviously real APIs are much more complex. For example you have to authenticate, you can hand over parameters and so on. You have POST, GET, DELETE Methods.
But this is simply the basic concept of an API.
Look here to know how to create an API (for example in Java): https://spring.io/guides/gs/rest-service/
Look here to know how for example an Mobile App consumes the API (in JavaScript): https://www.taniarascia.com/how-to-connect-to-an-api-with-javascript/
I hope i could help you :)
Best regards
Sebastian
My single page app is hosted on Google's cloudstore. I love that I don't have to worry about a server. The app is, naturally, javascript heavy.
Now I would like to add a feature where users can store some data, generate a link to be shared with others and retrieve stored data. Think of a pastebin where some snippet of text is saved and a unique link is generated to be shared with others.
In fact, if it helps, think of this as my attempt to create a pastebin without having to setup a server.
It looks like Google's cloud datastore nosql solution is what I want. Given a key, it will return a snippet of text. However, all the examples on the documentation page imply that I have to setup a back end service using python, node, etc.
Questions:
Can't I just read and write from a web page, perhaps using ajax style http call (since I need to get and put text snippets once data has already been loaded)? I believe I can take care of cross-origin issues by changing some configs in the cloudstore static website server.
Obviously I don't want to serve any encryption keys from the web page. I'm hoping that since my site is served from Google as well, I can configure the nosql service handle permissions intelligently for this scenario.
Is there any documentation which shows how to do this correctly?
Google Datastore is not supposed to be used from client side, it's a served side database. You cannot do that w/o having server side code to authenticate, authorize and validate db related requests.
But there're an alternative. Firebase is a ready to use backend for client side applications, including Javascript apps. It's a separate project, that belongs to Google but not (yet?) part of Google Cloud. Take a look - https://www.firebase.com/
Although the API Rest is still beta, it is possible now to connect from a web client or anything RESTful capabilities. https://cloud.google.com/datastore/reference/rest/
So, I'm starting out building a social network web app. I'm looking into how to fit the parts of my stack together and I'm looking for some guidance about what various frameworks will allow me to do. My current stack idea is to have:
Firebase JSON API: serving user, post, comment, and all the other data
EmberFire: to plug that API into EmberJS
EmberJS: my front-end MVC (because I'm new to MVC and Ember seems the most accessible)
What I'm stumbling on at the moment is how I'm going to implement users with this stack. I've looked at basic authentication stuff but I haven't found anything that would allow me to allow certain actions and views for certain users and not others - the basics of a social network really.
Is it sensible to be doing this stuff in front-end MVC? If so what should I be using to do authentication/personalisation? If not, should I just be doing a PHP/SQL setup? I'd rather avoid that because my skills are all front-end.
If you are just getting started, Firebase is a great service to learn on due to their 'back end as a service' model - you will spend more time building/modeling your data and less time running/installing. Not that you won't want to learn more about that later, but it lets you focus on one piece at a time.
From an access perspective, JS/NoSQL vs PHP/MySQL isn't going to be the issue. They each have their own security requirements - it's more that PHP/MySQL has had more time to establish those rules. Additionally, Firebase being a hosted service has it's own set of requirements.
Firebase security rules are a little weird when you first look at them, but they begin to make some sense after you sit with them for a bit. The Firebase docs are actually a pretty great resource. https://www.firebase.com/docs/security/
Basically, if you use a Firebase 'login provider' it makes Firebase act as both a database and a authentication manager, and the combo helps keep users 'fenced' to where you want them. You can use data from other paths, variables, validation rules, etc. You can even make a 'custom login provider' if you need to integrate with an existing one.
Finally, on the client end, your view can respond to whatever Firebase returns - if a user does 'hack' their way through to a page they shouldn't be on client side, no data is returned anyways and no submitted information would be allowed because of the rules.
I am developing an API for a social network website. This API will basically get all the requests from the users (get friend list, post a status update etc) and reply back if necessary.
We will implement OAuth 2.0 protocol for authentication. Consumer (our php project) has API id and secret.
Basic scenario:
Client wants to log in
API Consumer (php web project) takes this request, directs user to API
User send his/her user credentials to the api, gets the token.
User comes back to our website, pass token to the consumer.
Consumer goes to the api server, gets the access token.
Now consumer (php project) has access to user's private information.
Since this is a social network website, we want app developers to be able to use our API in the future.
I am not experienced in API-design. Does that flow make sense? I guess the simplest authentication would be accessing user information through php project. But we don't want to access database in php code. We will use ajax in client side and send a request to the API. And I believe there should be a better solution, what would you suggest?
Sure, API design is basically point where you need to choose technology.
Either it can be PHP or .net or Java.
I would prefer either PHP or .Net as we get lot of flexibility in it.
API will return XML or Json depending upon the request.
There are lot of CMS in php which can be helped.
.net we have Service Stack to help you.
API's had to be fully independent from other world as well as within API method as well.
If you are able to achieve this, then you will surely create a good architecture.
We are currently working on a web client that communicates with the server using AJAX with JSON. The client is based on gwt, and communication is over https.
The communication can be easily inspected by browser tools - is there some reasonable approach to hide this from the user, i.e. securing the protocol?
Other than standard authentication and encryption techniques used by all browsers, whatever method you come up with, it must be initiated by your JavaScript client. This means that a good hacker can deconstruct your JavaScript and figure out how you submit data.
Security usually deals with either third parties trying to intercept communication or pose as legitimate users, or malicious users trying to get access to where they are not supposed to. Once you verified that a user is legitimate, why would you try to hide user's data from the user? Maybe you can describe your use case.
EDIT:
The only way to prevent bots is to ask a question that only a human can answer (e.g. Captcha) somewhere in the workflow (i.e. before submitting important data). It's usually annoying for users, but there is no other way. Since you build a gaming platform, ask your designer to come up with some fun verification.
Just to Round off Security Checklist
1) HTTPS - you have got it set up already :)
2) Json and XSS/XSRF Web Security -
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json-xsrf
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#json
3) BOT attacks - A decent captcha - Captcha in GWT Widget
4) Miscellaneous - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/_gViO5aZ-WQ