I would like to ask what is the concept of "shopping cart"? Record item and do the calculation? If I want to write such a program, which approach should I take: using client side language or server side language? I think it would secure if I use server side language, but how can I store the information other than using cookie and store the data in client's hard disk?
if you don t want use cookie you need to feed your database table "cart" with the id product, the quantity, the price, and the user id
of course this work only if the user is logged, it s why prefer use cookie for unlogged users
Related
Hello Django REST API Experts,
We are building University Course portals where app offers various user types like Professor, Students and Admins using DJANGO/REACT. We are using REST API to connect between backend and frontend.
So, far we are able to perform some basic operation and it really works great. However now I need help from this group to do following:
When students enrolled in course it generates an acknowledge document stating course description, and its prerequisite which needs to get signed by students to ensure student acknowledge they fulfill these requirements.
In order to do this we have following:
Model for each course which contains the Content, Description and Prerequisite for each course.
StudentCourseAck Model which has FK to Course, Signed Boolean field, Binary field to store signed doc.
User flow:
Student logins to portal,
Select the Course, which generate StudentCourseAck entry.
Let Student review document and signed the document (on client side using sign pad).
The Signature gets stored in PDF (as binary field).
So far so good…
Now we want to enhance the featureset which allows admin to email student the link of studentcouseack document incase its not signed before course start. Also this link should only be valid for 48 hours or else it will expire.
So we need some help to enhance these featuresets as follow:
Current the API is exposed to frontend like: mysite.com/courseack/studentid/documentid
However we want to encrypt this so the link look like this: mysite.com/uniqueid
Where uniquid is mapped to /studentid/documented
So I have following design question:
Question 1: Should we enhance StudentCourseAck which store the UUID for each document?
Question 2: If I store UUID for each document, how do I make it expire once its generated?
Question 3: When Student is finished signing, I need to update the document into database to ensure that right document is saved to right student profile, so how can I ensure this security requirement.
I would really appreciate some expert opinion or some guidance so we can proceed this feature implementation. Any other alternative which is simpler and easier to maintain.
Once again thank you for your time and consideration.
Thank You.
Any other alternative which is simpler and easier to maintain.
Keeping the above phrase in mind I propose this solution.
Firstly I will not consider this as a DRF problem but as a general problem and proceed to answer your Questions.
The simple solution lies in 4 steps
Create a UUID field inside StudentCourseACK so that you can map this uuid with your url mysite.com/uniqueid, catch the document id inside the StudentCourseACK record as a foreign key and also create a created_at inside the model (this will be required for expiry timer)
Make a view inside your views.py that takes this StudentCourseACK UUID as a url parameter where you will have to fetch courseack, studentid and documentid from this StudentCourseACK mapping table and redirects it to mysite.com/courseack/studentid/documentid. When you link this view with your url pattern make sure the listing is at the very bottom.
To make an expiry timer you can check the created_at date in your StudentCourseAck record for 48hours limit before redirecting inside Step 2
Finally when the student is redirected to the mysite.com/courseack/studentid/documentid endpoint you will have to follow a simple process of getting the StudentCourseAck data via .filter(studentid="some value", documentid="somevalue") and make changes to this data accordingly.
Another thing that I realise is that you can completely ditch the long mysite.com/courseack/studentid/documentid url and correspond it's logic inside the new view, but I assume that you want to keep it that way.
What is the exact use of session ID, is it system generated or we assign it as we assign other dictionary values of session ? Please explain in layman terms.
The Django Session Documentation give a good explanation as well as providing great examples. Give that a read and you should have a good idea about how you can use sessions with Django.
Essentially it gives a good way to associate data with anonymous users, for example I just built a site where users add items to their cart and purchase the items. To be able to do that without requiring them to sign up for an account, I used session data.
Here are some Example Code of how to use session data.
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)
When thinking about security and user experience, what information id OK, acceptable, or even a good idea to store in a cookie?
EDIT:
With the understanding that sensitive info, like user names, passwords, SSN, credit card numbers don't belong there, what does?
Definitely not passwords! Or anything sensitive... remember that cookies are stored on people's computers so from your point of view (as a website developer), they're basically out in the wild, potentially accessible to anyone.
A common practice is to just store a session ID in a cookie, and store all other relevant information in a database (or file, or whatever) on the server, indexed by session ID.
It's a lot easier to answer what's not acceptable to store in a cookie. Anything that should remain secure shouldn't be stored. That includes passwords, credit card numbers, social security numbers, etc.
I think it's okay to store a user's login name, since that information really isn't sensitive. A user's preferences settings for your site should be okay as well.
Remember, cookies are just plain text files that someone (or some application) can open up and read or write, so you shouldn't trust information you receive from a cookie, either. Sanitize it just like any other user input.
One suggestion is that you not store any keys to your database in cookies. i.e. email addresses, column ID's etc. If so, you should encrypt the data.
User customization ID (a set of preferences stored in a db which you fetch on page load)
No personal information
Well other than sensitive and security related data there really is no limit to what you can't and can store but just remember that if that data is not persisted on the server side, it could be lost altogether and it should be assumed that if the user deletes cookies, it won't inconvenience him too much to restore his settings/configuration. There are no guidelines other than using good common sense here.
There are however limits to cookies. You should not exceed 19 cookies per domain and no cookie should be bigger than 4KB (4096 bytes) as per IE limits:
Each cookie begins with a name-value
pair. This pair is followed by zero or
by more attribute-value pairs that are
separated by semicolons. For one
domain name, each cookie is limited to
4,096 bytes. This total can exist as
one name-value pair of 4 kilobytes
(KB) or as up to 20 name-value pairs
that total 4 KB. If the computer does
not have sufficient space to store the
cookie, the cookie is discarded. It is
not truncated. Applications should use
as few cookies as possible and as
small a cookie as possible.
Additionally, applications should be
able to handle the loss of a cookie.
If a Web application uses more than 19
custom cookies, ASP session state may
be lost. Internet Explorer 4.0 and
later versions allow a total of 20
cookies for each domain. Because
ASPSessionID is a cookie, if you use
20 or more custom cookies, the browser
is forced to discard the ASPSessionID
cookie and lose the session.
Don't store anything in a Cookie that will allow your site to be hacked or accessed without going through proper channels. Usually, just a session ID or user ID is stored in a cookie, and often in a form intended to be opaque to anyone but the cookie consumer.
I would avoid storing anything that, if altered, would compromise the functionality of the site.
So, storing something like a user id, shopping cart items' prices, password, user roles, etc. are problematic. I keep this kind of thing in the user's session data on the server.
Storing a user's name or profile info (for display purposes only), customization preferences (colors, text, whatever) are fine.
There is nothing wrong in saving sensitive information on a cookie, as long as that information is encrypted (the data itself is not clear text) and the cookie is a secure cookie (https). Actually it is much worst to have all of the sensitive data in one DB server that might be hacked and then you are facing a potentially much bigger security issue.
You're building a web application. You need to store the state for a shopping cart like object during a user's session.
Some notes:
This is not exactly a shopping cart, but more like an itinerary that the user is building... but we'll use the word cart for now b/c ppl relate to it.
You do not care about "abandoned" carts
Once a cart is completed we will persist it to some server-side data store for later retrieval.
Where do you store that stateful object? And how?
server (session, db, etc?)
client (cookie key-vals, cookie JSON object, hidden form-field, etc?)
other...
Update: It was suggested that I list the platform we're targeting - tho I'm not sure its totally necessary... but lets say the front-end is built w/ASP.NET MVC.
It's been my experience with the Commerce Starter Kit and MVC Storefront (and other sites I've built) that no matter what you think now, information about user interactions with your "products" is paramount to the business guys. There's so many metrics to capture - it's nuts.
I'll save you all the stuff I've been through - what's by far been the most successful for me is just creating an Order object with "NotCheckedOut" status and then adding items to it and the user adds items. This lets users have more than one cart and allows you to mine the tar out of the Orders table. It also is quite easy to transact the order - just change the status.
Persisting "as they go" also allows the user to come back and finish the cart off if they can't, for some reason. Forgiveness is massive with eCommerce.
Cookies suck, session sucks, Profile is attached to the notion of a user and it hits the DB so you might as well use the DB.
You might think you don't want to do this - but you need to trust me and know that you WILL indeed need to feed the stats wonks some data later. I promise you.
I have considered what you are suggesting but have not had a client project yet to try it. The closest actually is a shopping list that you can find here...
http://www.scottcommonsense.com/toolbox.aspx
Click on Grocery Checklist to open the window. It does use ASPX, but only to manage the JS references placed on the page. The rest is done via AJAX using web services.
Previously I built an ASP.NET 2.0 site for a commerce site which used anon/auth cookies automatically. Each provides you with a GUID value which you can use to identify a user which is then associated with data in your database. I wanted the auth cookies so a user could move to different computers; work, home, etc. I avoided using the Profile fields to hold onto a complex ShoppingBasket object which was popular during the time in all the ASP.NET 2.0 books. I did not want to deal with "magic" serialization issues as the data structure changed over time. I prefer to manage db schema changes with update/alter scripts synced with software changes.
With the anon/auth cookies identifying the user on the client you can use the ASP.NET AJAX client-side to call the authentication web services using the JS proxies that are provided for you as a part of ASP.NET. You need to implement the Membership API to at least authenticate the user. The rest of the provider implementation can throw a NotImplementedException safely. You can then use your own custom ASMX web services via AJAX (see ScriptReference attribute) and update the pages with server-side data. You can completely do away with ASPX pages and just use static HTML/CSS/JS if you like.
The one big caveat is memory leaks in JS. Staying on the same page a long time increases your potential issue with memory leaks. It is a risk you can minimize by testing for long sessions and using tools like Firebug and others to look for memory leaks. Use the JS Lint tool as well as it will help identify major problems as you go.
I'd be inclined to store it as a session object. This is because you're not concerned with abandoned carts, and can therefore remove the overhead of storing it in the database as it's not necessary (not to mention that you'd also need some kind of cleanup routine to remove abandoned carts from the database).
However, if you'd like users to be able to persist their carts, then the database option is better. This way, a user who is logged in will have their cart saved across sessions (so when they come back to the site and login, their cart will be restored).
You could also use a combination of the two. Users who come to the site use the session-based cart by default. When they log in, all items are moved from the session-based cart to a database-based cart, and any subsequent cart activity is applied directly to the database.
In the DB tied to whatever you're using for sessions (db/memcache sessions, signed cookies) or to an authenticated user.
Store it in the database.
Do you envision folks needing to be able to start on one machine (e.g. their work PC) but continue/finsih from a different machine (e.g. home PC)? If so, the answer is obvious.
If you don't care about abandoned carts and have things in place for someone messing with the data on the client side... I think a cookie would be good -- especially if it's just a cookie of JSON data.
I'd use an (encrypted) cookie on the client which holds the ID of the users basket. Unless it's a really busy site then abandoned baskets won't fill up the database by too much, and you can run a regular admin task to clear the abandoned orders down if you care that much. Also doing it this way the user will keep their order if they close their browser and go away, a basket in the session would be cleared at this point..
Finally this means that you don't have to worry about writing code to deal with de/serialising the data from a client-side cookie, while later worrying about actually putting that data into the database when it gets converted into an order (too many points of failure for my liking)..
Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.
Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in
I'd say store the state somewhere on the server and correlate it to the user's session. While a cookie could ostensibly be an equal place to store things, if you consider security and data size, keeping as much data on the server as possible becomes a good thing.
For example, in a public terminal setting, would it be OK for someone to look at the contents of the cookie and see the list? If so, cookie's fine; if not, you'll just want an ID that links the user to the data. Doing that would also allow you to ensure the user is authenticated to the site in order to get to that data rather than storing everything on the machine - they'd need some form of credentials as well as the session identifier.
From a size perspective, sure, you're not going to be too concerned about a 4K cookie or something for a browser/broadband user, but if one of your targets is to allow a mobile phone or BlackBerry (not on 3G) to connect and have a snappy experience (and not get billed for the data), minimizing the amount of data getting passed to the client will be key.
The server storage also gives you some flexibility mentioned in some of the other answers - the user can save their cart on one machine and resume working with it on another; you can tie the cart to some form of credentials (rather than a transient session) and persist the cart long after the user has cleared their cookies; you get a little more in the way of fault tolerance - if the user's browser crashes, the site still has the data safe and sound.
If fault tolerance is important, you'll need some sort of persistent store like a database. If not, in application memory is probably fine, but you'll lose data if the app restarts. If you're in a farm environment, the store has to be centrally accessible, so you're again looking at a database.
Whether you choose to key by transient session or by credentials is going to depend on whether the users can save their data and come back later to get it. Transient session will eventually get cleaned up as "abandoned," and maybe that's OK. Tying to a user profile will let the user keep their data and explicitly abandon it. Either way, I'd make use of some sort of backing store like a database for fault tolerance and central accessibility. (Or maybe I'm overengineering the solution?)
If you care about supporting users without Javascript enabled, then the server side sessions will let you use URL rewriting.
If a relatively short time-out (around 2 hours, depending on your server config) is OK for the cart, then I'd say the server-side session. It's faster and more efficient than accessing the DB.
If you need a longer persistence (say some users like to leave and come back the next day), then store it in a cookie that is tamper-evident (use encryption or hashes).