I am developing a website in asp.net in which I am developing user notes, for this purpose I have implemented notes in HTML5 and store the data in local storage and then save it into the database but the problem is this I have many user opened in different tabs and I want to show each user to his own notes so I can handle it with local storage?
see, in html5, local database store data in your browser.
so you can manage your database for particular browser.(like session and cookies)
Even if you open your page in different browser, you will not get your data that you have stored in last browser.
so if you want to store data for particular user in different browser then you can use inbuilt database of html5 otherwise you have to store your data on server side.
Related
What is the best place to store the JWT token in the Angular website. I know we can store it in localstorage but that can be easily accessed by JS scripts. I have read so many answers on the google and now I am confused which one to use.
Every place you can store the token in the frontend can be accessed by js scripts.
That being said the most common practices are localStorage and sessionStorage
Use localStorage when you want the token to persist between tabs and not end the session after browser window is closed
Use sessionStorage when you want the token to be unique to each tab and to be deleted when tab or browser is closed.
You can also store it in cookies or frontend databases as Kiran mentioned
You can store token at many place it's depend upon your choice basically many developer store token in local storage but you have many ways you can try or you can use it.
local storage
you can store token in local storage but you are telling easily accessed by JS and also you can edit token from local storage section under console.
index DB
index Db is a package in angular which is second option you can use it it provide all function like set, get, delete and so on. the main advantage you cannot edit it's value from console you can try it.
cookies
In cookies you can store token but may be it easily accessed by JS.
I think index DB is a good for storing token and if you want then you can try it
Given a mobile app with no authentication, I was looking for the most suitable way to keep user's setting without any authentication. That mean in my database I won't have a user table to link with another table keeping his settings.
I thought about a in-app database such as sqlite. But I'm afraid that with some manipulation it get erased when the user turn off his phone.
What would you suggest ?
Well if it's your application and you can modify it, then use the device IMEI and create a table to save settings for that device.
If you don't want to create a table then i suppose the only option is to save it locally on device but like you said there is a chance that might get wiped away so best bet is to keep it on server. As device IMEI won't change you can always check it at first startup and retrieve settings.
I am creating an app with user login using sqlite i am storing the login details which includes the users favorite movies.suppose another user who has downloaded the app also picks the same movie i want to be able to let the other 1st know about 2nd user.how do i do that.does the sqlite db used to store login details be available for the other user or should i have server to upload each user's login details?I think my confusion is stemming from the fact that i dont understand how people use sqlite in iphone app ?
In very rare instances SQLLite should be used directly. The best way to handle data storage local to an iOS device is CORE DATA. I would suggest you consider using Core Data for storage and not call or mess with SQL Lite directly.
Explanation of the problem:
Right now my asp.net mvc 3 application is using cookieles="auto" setting which I really hate and I am trying to find something that will allow me to turn that feature off.
So I came across HTML5 storage solutions and I am having some trouble understanding the idea behind it. So basically all I need to do is take my userID variable and move it from one page to another and then on the backend I pull out this userID and pass data to view as a model. Now, how can I do it without cookies and using HTML5 storage? If it's only accessible via JavaScript do I need to pass it via ajax to my controllers? But I don't see any sense in this since I already passed my model to the view with empty userID because the cookie was empty.
Is there a way to access the HTML5 storage in the backend? Maybe I am missing something here, please advise!
No, there's no way except javascript code, which will read storage content and send it to backend. For small portion of data, which should be available to the server, use cookies.
Local storage was created specially for content, which will not be transfered to the server with each request and therefore allowing to store more data, than cookies w/o traffic spoiling.
We have several wizard style form applications on our website where we capture information from the user on each page and then submit to a backend process using a web service.
Unfortunately we can't submit the information in chunks during each form submission so we have to store it the users session until the end of the process and submit it all at the same time.
Is the amount of server memory/sql server disk space the only constraint on how much I can store in users sessions or is there something else I need to consider?
Edit: The site is built on ASP.NET web forms.
Assuming the information is not sensitive then you could store the information in a cookie which would reduce the amount of information required to be stored server side. This would also allow you to access the information via JavaScript.
Alternatively you could use the viewstate to store the information although this can lead to large amounts of data being sent between the server and the client and not my preferred solution.
The amount of session information you should store varies wildly depending on the application, number of expected users, server specification etc. To give a more accurate answer would require more information :)
Finally, assuming that the information collected throughout the process is not required from page to page then you could store all the information in a database table and only store the records unique id in the session. As each page is submitted the db record is updated and then on the final page all the information is retrieved and submitted. This is not an idea solution if you need to retrieve previous information on each subsequent page due to the number of db reads required.
You could also have 1 asp page with the entire html form, and hide parts of it until the user fill and "submits" the visible part...
then simply hide the part that is filled out and show the next part of the form...
This would be extremely easy in the .NET framework, use panels for each "wizard step" and add loggic when to display and hide each panel.
you will then have all the data on one page.
If you use a traditional HTTP model (i.e. don't use runat="server") you can post the data to another asp page and place the posted data into hidden form elements, you can do this for however many pages you need thus avoiding placing anything in a session variable.
Since it is problematic from performance point of view to store large amounts of data in user Session object, ASP.Net provides some other workarounds on top of what is mentioned in the posts above. ASP.NET Profile Provider allows you to persist session related information in a database. You can also use Session State Server which uses a separate server to store all Session information. Both of these situations take into account if you need to use clusters or load balancers, the servers can still recognize the session information across different servers. If you store information in the Http Session object, you run into the problem that one user must always go to the same server for that session.
Session, viewstate, database. These are all slow but will get the job done.
Hidden form fields is the answer I like best.
There are other ways to persist state. Cookies, popup window, frameset or iframes.