Is making a shopping cart using IndexedDB a good idea rather then the implementation of Sessions and cookies if we support only modern browsers?what difference it can make in comparison with session and cookies?(skipping compatibility issue)
Use indexedDB if you need scalability over localStorage, sessionStorage, or cookies. Otherwise there is not much point, as indexedDB is more complicated and slower.
Related
After reading some articles, I realize that using localStorage and sessionStorage is a bad idea for storing JWT tokens, and cookies with httpOnly should be used instead.
As I read more and learn some about indexedDB today, I wonder if indexedDB is a secure option for storing JWT tokens as well?
The short answer is NO, as you are pretty much convinced using localStorage and sessionStorage is a bad idea. IndexedDB is also vulnerable to cross-site scripting (XSS) attacks similar to local storage.
Regardless of security -
IndexedDB API is powerful but may seem too complicated (I'd go so far as to say 'horrific') for simple use cases such as storing jwt token. Because, even for this implementation, you will have to write more code. (More code, which means maybe more bugs). Just be aware of the steep learning curve when you're getting started with it.
IndexDB is not actually designed for such use cases. It is designed to work with significantly larger amounts of structured data. For basic key-value operations, IndexedDB performance takes a hit.
Browser support for IndexedDB isn't also quite good.
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
Me and some friends are going to develop a web site with playframework and a mobile application (android and iphone). So we need to make some webservices for the mobile application(CRUD). So we thought about using this web services in our playframework application instead of wasting time and creating the CRUD with anorm(writing all the sql requests).
Well, I'm here to ask for your opinion. Is this a good thing to do ? What's the best advised method here ?
Thank you.
PS: the web services are automatically generated with Netbeans from our database.
There are various reasons why I would advice against this approach.
A general design rule is not to expose your internal data model to the user. This rule comes in many flavors in which the layered architecture is probably the most known one.
In detail there will be issues like:
Tuning performance: This is hard to achieve because your have no, or not much control over the generated web services. When your application is really taking of your will suffer from this limitation
Access the service: I don't know whether you generate RESTful web services or WS-* ones. The latter will get you in trouble when accessing them via iphone.
Design Play vs. synchronous web services: Also somehow related to performance is the issue that the generated service is likely synchronous, blocking, which does not fit well with the non-blocking approach which the play framework is taking.
Abstraction level: Because your database is based on sets but your business model is likely not, you will have issues developing a decent client, tuning the performance, doing proper validation, security, etc.
Authentication, authorization and accounting: Hard to do because the database only knows the db system users
Change: What if you change your database model? Will the generated services continue to work? Do your have do adopt them event if you just add a column?
...
Some of those reasons do overlap, but I think the general problem should be clear.
Instead of this approach I would recommend the following. Develop a RESTfull endpoint for your app, which is not that hard to to. This is the external contract against which the clients should be developing. play-mini for example has a very need, Unfiltered based, API to do this. While doing this, focus on the operations your app really needs. CRUD in general is a bad model when thinking about production ready software.
How you access your database is another decision your have to make but probably it is not that important because it is not your external contract so your can change it when your have the need for doing so.
I plan to make an online game. It will be a full real-time during play. For my website backend I have used Django. Database and other things are almost done. What is the best way to make user client side and server side backend for play in realtime? As I use Django it would be nice to have it in Python.
We plan that there will be minimum ~1000 online players all the time.
Twisted/Tornado/Node.js or maybe something else?
Thanks in advance.
Tornado is very light and pretty nice in my opinion. You could integrate it with Django in various ways -- e.g. Integrate Tornado in Django, Integrating Django with Tornado's web server -- or just run it alongside Django behind whatever web server you use.
Node is so fun that you might tire of Django. :-)
I think you should keep separately Django - which is used for general site functions, and Tornado - which is used for realtime data. I think you should use some Redis to store/read data and communicate between django and tornado, so prevent using database access directly from tornado.
Developing your own backend server sounds as interesting project.
But from my experience it becomes a very significant of your R&D effort.
It starts with developing core backend components, dealing with servers, installs, patches, security issues and more.
On top of it, you will need to create admin systems to manage your player, levels, xp, integration to stores and more... and then, you have the reports (installs, retention, etc'...)
I would strongly recommend using existing backend platforms.
I'm new to web development and I'm trying to develop my own prototype. There are certain ragged edges with my code. I'll lump together making the markup cross-browser compatible, detecting if JS is turned on for the client browser, and testing if cookies are enabled for client.
General question, but does pretty much every site out there test for cookies within their login view? I know how to do this, I was just curious if it's so blatantly necessary.
Obviously, if cookies are disabled, the auth framework won't work. How often do clients turn off cookies these days?
Might be a naive question or I may have answered myself but hey, I'm curious.
Brendan
Cookies and other authentication are handled by the session Middleware in Django. The pylons documentation has a bit more detailed explanation of how WSGI handles requests/responses, and how they make their way from the server, up into your code here.
Typically in Django, you use the #login_required decorator in your views, and the Session middleware handles the implementation details (like clients who have cookies disabled, as you mentioned).
For other stuff that you can put in a cookie, you use the Httprequest.Cookies array.