I have a sencha touch client application and restful web service with OAuth2 authorization protocol. I want to know , how I can hold access_token in my client application for further using. Now, I use a global variable to hold token, is it the best way to do that?
Well, you can use a Store to save the data and keep it in localStorage or sessionStorage.
Store is a good tool and keep the code clean.
Update
Best pratices are about maintainability (legible code), efficiency, dependability, usability. So if you a framework the best pratice is use its tools. With that any programmer that have knowledge about it will understand the code faster.
With store you can keep data even in localSession or sessionStore so you have full control how long you want to save the data.
Other advantage with store you can keep multiple user or agroup multiple data with it without have to do a lot of work (like profile or other data you need to save).
Sure, you can use your global variable without problem. But in my personal opnion if you use a framework use the tools.
Related
I mainly have two questions. I haven't read this anywhere but, I am wondering whether or not it is a good idea to make it so that all the data that is going in and out of all apps in your project solely depended on REST API calls.
So that if you, for instance, want to register a new user. Gather the data from a front-end, with no back-end work, and just send this data as a REST call to you "registration-app" where all validation and back-end work is done.
I find this method effective when working in big teams as it makes dependencies even more decoupled, as well as making each part of the project more separated and "clear". My question is, therefore, is this a viable way of developing? Are there any security or performance issues with this? And where can I read more?
Thanks
Max
It is perfectly viable, I think like most choices it has pros and cons. Here are some of them:
Pros:
Decoupling - Clients depend on the abstraction (i.e. the REST API) rather than the concretion (i.e. the website), so you gain clarity of design, ability to test outside of the browser, and you can do things like substitute the REST API with different implementations e.g. with a mock service for development/testing purposes. If, in addition, the REST API is implemented by a separate back-end service, then you can update it independently, and potentially scale it independently.
Responsive user-interface - The REST requests can avoid HTML page reloads and improve UX. Also you can make asynchronous REST calls.
Reduced payload - Typically the REST calls would return less data than the HTML sent in a page refresh.
Cons:
More complex client - You require more complex javascript and especially so if you employ asynchronous REST calls.
Dynamic page building - Typically the result of a REST call might require some change in the UI, you are forced to do this dynamically in javascript which also adds complication. So your UI logic is split between your HTML page templates and your javascript UI updates. This makes the UI hard to reason about.
Timeouts - You need to handle timeouts and errors in javascript
Sessions - You need some means of authenticating users and maintaining sessions. REST services should not maintain client-session state themselves, so you either need to store state in the client, or explicitly add state as a new REST resource with its own distinct URI(s).
Forced page reload - If you use this mechanism to avoid page reloads, then users potentially might have the page open for a significant period of time, and you might need some kind of mechanism to cause them to reload it.
I am having large list of data of ingredients required for cooking. More than 3000+
I am using Django rest framework as the backend and ReactJs as frontend.
Each item in the list has a name, id, measurementunit, density in kg/ltr and cost/measurementunit
In Django i have created an api endpoint to supply the data in JSON format.
I want to display the data in a table format and with search filter on the top. Also at a time i want to show maximum 300 results.
Can someone guide me how to achieve this. Should i fetch all the list at a time or use pagination from django. Should i use seperate api for search or do it using reactjs on the frontend.
Presently i dont need any authorization in django. The data is for local use only.
3000 records is a lot to send down to the client in one chunk. It is easier to develop against, but it doesn't scale well and is likely to create a measurable load time. If you're OK with that, and you don't expect your data set to grow, then perhaps the pragmatic approach is to keep it as a big list... but it goes against best practices.
Either way, you likely don't want to show a giant 3k-row list to the user, so the UI will have some sort of pagination mechanism. That might be "next", "previous" pages, or it might be infinite scrolling. Either way, the data abstraction should be considering it as paged data.
Paging API
Assuming you decide to make your API support paging, you should use the backend framework's paging capabilities, like the Django Paging API or some other abstraction for your REST API. There are lots of resources out there.
Search
The moment you decide to paginate the API, you are committing to handling search (filtering) on the backend as well. The only way you can manage client-side filtering is if the client has access to all the data. Since that isn't the case, you'll need to include a search filter in your data request. Searching and pagination aren't mutually exclusive, so make sure your API supports both at the same time. A common way to handle this would be like this:
http://yoursite.com/api/ingredients?page=5&page_size=100&search=carrot
Client
On the React side, you can build your own UI (it is easy to do), or you can use a component which abstracts this for you, like react-js-pagination or react-paginate. The client component shouldn't really care if the API is paged or not. Instead, it just notifies you when to display different records and the rest is up to you.
If you decide to keep everything in one big REST call, then you still need to slice the data out of your array to display. If you paginate your API, then you can keep an instance cache on the client side of the pages you've received. If you don't have the data, make the REST call to get it, and populate an array with the data. That way, if a user goes forwards and then backwards, you aren't re-fetching.
Conclusion
I hope this helps a bit. Enjoy :)
I have just started playing around with django. I can foresee one app generating data that another could use (bad example: a geomatics app crunching complex data to generate simple location data to pass to another app that uses the data to decide some sort of business logic). Having never done any web programming with frameworks, my first thought was ....globals... But thats obviously not a "good thing"!
Return a key to the client (either via a cookie or in the session) that can be used to retrieve the information from a datastore when needed.
I need a way to stash some data that is global to the browser. If I open a new window with a URL from my app, e.g. via a bookmark, I need to access some data that was created in another window and never sent to the server.
As far as I can tell the only thing that is global to the browser and not just a window, (like window.name), is a cookie. The problem I'm running into is if I set a cookie the cookie is then sent with every request to the server, but I don't ever want this data on the wire. Is there any way to set a cookie and just use it purely as a bucket for storing some data and never send that data to the server?
The HTML 5 storage API looks like exactly what you want here, but unfortunately it's only supported by a handful of browsers right now.
Is there any way to set a cookie and just use it purely as a bucket for storing some data and never send that data to the server?
No.
You'll need to look into a plugin that provides dedicated offline storage facility, or use the HTML5 storage API and tell everyone to upgrade their browsers
If you decide to go the plugin route, as far as I am aware you have 3 options:
Google Gears
Flash - it has an offline storage facility - you could write a small flash app to store things using this facility, then interop with it from javascript.
Silverlight also has offline storage - as with flash you could write a small app to do the storage, then interop with it from javascript.
I'd probably look into using flash first, as everyone already has it.
Development would likely be a lot easier if you were to use silverlight. It's not as widely installed, but it is spreading pretty rapidly. Last I heard* something like 30% of browsers had it installed which is pretty impressive.
Google gears would unfortunately be a distant third. People are going to be installing flash and silverlight for other reasons, but nobody has gears.
*This is an entirely unsubstantiated quote, but does seem to fit with what I've seen on various people's computers, etc.
Can you mandate that your users install Google Gears? It's a javascript API that lets you store local info- also lets you persist between sessions, which may be useful for your app.
Why not just read a field in the parent window using window.opener ? Or if you've three windows running - parent and two children which I think you might be implying then read/write to a hidden field in the parent from the children.
Sounds like your app is running 100% local, if that is the case the browser isn't the way to go anyway. Cookies can be easily deleted. If your app isn't local the webserver should be the one supplying information. Cookies are never the correct way to store sensitive information or information that should persist over longer amounts of time.
There are various ways to maintain user state using in web development.
These are the ones that I can think of right now:
Query String
Cookies
Form Methods (Get and Post)
Viewstate (ASP.NET only I guess)
Session (InProc Web server)
Session (Dedicated web server)
Session (Database)
Local Persistence (Google Gears) (thanks Steve Moyer)
etc.
I know that each method has its own advantages and disadvantages like cookies not being secure and QueryString having a length limit and being plain ugly to look at! ;)
But, when designing a web application I am always confused as to what methods to use for what application or what methods to avoid.
What I would like to know is what method(s) do you generally use and would recommend or more interestingly which of these methods would you like to avoid in certain scenarios and why?
While this is a very complicated question to answer, I have a few quick-bite things I think about when considering implementing state.
Query string state is only useful for the most basic tasks -- e.g., maintaining the position of a user within a wizard, perhaps, or providing a path to redirect the user to after they complete a given task (e.g., logging in). Otherwise, query string state is horribly insecure, difficult to implement, and in order to do it justice, it needs to be tied to some server-side state machine by containing a key to tie the client to the server's maintained state for that client.
Cookie state is more or less the same -- it's just fancier than query string state. But it's still totally maintained on the client side unless the data in the cookie is a key to tie the client to some server-side state machine.
Form method state is again similar -- it's useful for hiding fields that tie a given form to some bit of data on the back end (e.g., "this user is editing record #512, so the form will contain a hidden input with the value 512"). It's not useful for much else, and again, is just another implementation of the same idea behind query string and cookie state.
Session state (any of the ways you describe) are all great, since they're infinitely extensible and can handle anything your chosen programming language can handle. The first caveat is that there needs to be a key in the client's hand to tie that client to its state being stored on the server; this is where most web frameworks provide either a cookie-based or query string-based key back to the client. (Almost every modern one uses cookies, but falls back on query strings if cookies aren't enabled.) The second caveat is that you need to put some though into how you're storing your state... will you put it in a database? Does your web framework handle it entirely for you? Again, most modern web frameworks take the work out of this, and for me to go about implementing my own state machine, I need a very good reason... otherwise, I'm likely to create security holes and functionality breakage that's been hashed out over time in any of the mature frameworks.
So I guess I can't really imagine not wanting to use session-based state for anything but the most trivial reason.
Security is also an issue; values in the query string or form fields can be trivially changed by the user. User authentication should be saved either in an encrypted or tamper-evident cookie or in the server-side session. Keeping track of values passed in a form as a user completes a process, like a site sign-up, well, that can probably be kept in hidden form fields.
The nice (and sometimes dangerous) thing, though, about the query string is that the state can be picked up by anyone who clicks on a link. As mentioned above, this is dangerous if it gives the user some authorization they shouldn't have. It's nice, though, for showing your friends something you found on the site.
With the increasing use of Web 2.0, I think there are two important methods missing from your list:
8 AJAX applications - since the page doesn't reload and there is no page to page navigation, state isn't an issue (but persisting user data must use the asynchronous XML calls).
9 Local persistence - Browser-based applications can persist their user data and state to the local hard drive using libraries such as Google Gears.
As for which one is best, I think they all have their place, but the Query String method is problematic for search engines.
Personally, since almost all of my web development is in PHP, I use PHP's session handlers.
Sessions are the most flexible, in my experience: they're normally faster than db accesses, and the cookies they generate die when the browser closes (by default).
Avoid InProc if you plan to host your website on a cheap-n-cheerful host like webhost4life. I've learnt the hard way that because their systems are over subscribed, they recycle the applications very frequently which causes your session to get lost. Very annoying.
Their suggestion is to use StateServer which is fine except you have to serialise/deserialise the session eash post back. I love objects and my web app is full of them. I'm concerned about performance when switching to StateServer. I need to refactor to only put the stuff I really need in the session.
Wish I'd know that before I started...
Cheers, Rob.
Be careful what state you store client side (query strings, form fields, cookies). Anything security-related should not be stored client-side, except maybe a session identifier if it is reasonably obscured and hard to guess. There are too many websites that have settings like "authenticated=true" and store those in a cookie or query string or hidden form field. It is trivial for a user to bypass something like that. Remember that ANY input coming from a client could have been tampered with and should not be trusted.
Signed Cookies linked to some sort of database store when you need to grab data. There's no reason to be storing data on the client side if you have a connected back-end; you're just looking for trouble if this is a public facing website.
It's not some much a question of what to use & what to avoid, but when to use which. Each has a particular circumstances when it is the best, and a different circumstance when it's the worst.
The deciding factor is generally lifetime of the data. Session state lives longer than form fields, and so on.