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.
Related
I want to setup a public form to write to Firebase via the Angular Firebase plugin AngularFire but it feels like there needs to be some security added so that data is only posted from that form, I can't see any interface to Whitelist a Domain/URL. Is there a way to only accept writes from a specific Form/URL without getting the User to login first?
Nope.
But it wouldn't help in your scenario anyway: when you're using Angular, all code is running in the user's browser. It might be served from your domain into that browser first, but just as easily the user might have saved the HTML locally and started running it that way.
It sounds like you're trying to secure things so that only your code can modify them, probably because you think that your code is the only thing that can be trusted to follow some of your application-specific business rules. Instead of trying to limit access to just your code, I'd instead recommend capturing the business rules server-side. Firebase has a very powerful security and data validation model just for that purpose. See https://www.firebase.com/docs/security/guide/
Once you enforce these business rules on the server, it doesn't matter how someone access your data. They could be using your code - or somebody could have taken your code (or an API that you've documented) and written a third-party application. Either way: the (security and validation) rules will be enforced by Firebase, so your data will stay valid and secure.
I'm working on an ASP MVC project using C#.
My question is basically which is the best place to store some data that you get at a given part on your website, say for example, on the method that handles the SignOn of the user to the site, and then you want to access that data on another parts of the website, say on the classes of your model layer.
Suppose the data is just a list of strings, what would be better, store it as a list or wrap the list with a class?
Thanks.
It depends on how long you need your data to be around.
In the case of a single request you could use TempData on the controller
If you only want to store it per session (aka next time the user logs on to the site it will be gone) you could use the Session
If you want to keep it around forever then you will need to use some sort of offline storage, such as a database or file of some sort.
Good luck.
Um, pardon my ignorance, but can't you store it in the database?
What do you mean by "shared"? Shared by whom, by different pages but the same user? Or by different users?
If the latter -> DB.
If the former, either TempData, or if your talking about "authentication" data, then store it in the forms authentication ticket (assuming Forms Auth).
I think similar question was asked before here is the URL
Session variables in ASP.NET MVC
YOU likely store them in a session
which is the best place to store some data that you get at a given
part on your website, say for example, on the method that handles the
SignOn of the user to the site, and then you want to access that data
on another parts of the website, say on the classes of your model
layer.
A database is a great candidate for storing such information. Or a cookie if it is user specific and you don't need it to last very long. Or a file on the server. Or on the Cloud. Or write a P/Invoke wrapper around a C++ unmanaged Win32 function that will deposit the data on your company's intranet FTP server. The possibilities that you have are close to infinity. Just pick the one that you feel most comfortable with.
And I am explicitly not suggesting you to use Session contrary to what others might suggest you.
I am using DotNetOpenAuth in my ASP.Net Website. I have modified it to work with Facebook Connect as well, using the same methods and database structures. Now I have come across a problem.
I have added a Facebook Connect button to a login page. From that HTML button, I have to somehow pull information from the Facebook Connect connection and pass it into a method to authenticate the user. The way I am currently doing this is by:
Calling a Javascript Function on the onlogin function of the FBML/HTML Facebook Connect button.
The javascript function calls a Web service to login, which it does correctly.
The web service calls my data access layer to login.
And here is the problem: FormsAuthentication.SetAuthCookie is set at the data access layer. The Cookie is beyond the scope of the user's page and therefore is not set in the browser.
This means that the user is authenticated, but the user's browser is never notified.
So, I need to figure out if this is a bad way of doing what I need or if there is a better way to accomplish what I need. I am just not sure and have been trying to find answers for hours. Any help you have would be great.
Yes, it sounds like you are having a design crisis brought on by trying to do too much at one time/in one place.
If you break this operation up in to two calls from the client you will find your options opening up quite a bit. It might take some more work but ultimately the code will be less complex. <-- a good thing.
And in my opinion, the first clue pointing to a crisis of design would be when I said to myself "Self, having an authentication method buried two calls deep in my DAL is not working the way I would like...." lol.... I am joking and serious same time.
Good luck.
we have some application that this is vital to prevent users from opening multiple tabs/windows per session on the website ?
Edit:
The reason is that those pages communicate with flash and we cannot know on server side whether the user has two windows open or not.
Of course you can suggest to make those changes in application design so it will use Flash Media Server as "token generator" but we cannot allow ourselves to change the infrastructure without good reason because it can take months
This is a bad idea - you are restricting how the user expects their browser to behave.
Don't do it.
The only way I could think of to reliably do such would be to have a session that kept track of a token which was updated each time a page was requested - links on the served page would all include the token, and when a page was loaded using that token, a new token would be generated (in essence, only allowing any page's links to be valid for a single use). However, this would break things like the Back button and whatnot, and thus isn't a very good solution.
What is so important that you have this requirement in the first place? Is there any way you could re-think your interface so as to avoid such?
If limiting the user to 1 interface at a time is vital to the app, you should consider writing it as a desktop application instead of a web application.
I want to enable an user to be able to communicate with other users through a site. I know that ASP.net is stateless, but what can I use for this synced communication? Java servlets?
I don't think you need to set up Java just to use a servlet for this. I would use AJAX and the database. I don't know ASP.NET but I PHP is similar in this case, being also basically "stateless". If you want to display some kind of asynchronous communication between two different users, say, from two different sessions, without a lot of refreshing (like chat), you can have the AJAX page constantly poll the database for new messages, and display them when they come in. You can also use AJAX to insert the new messages, giving the user read/write access to this messages data structure. Since the "other" user is doing the same thing, user A should see new messages pop up when user B types them in.
Is that what you mean?
You probably don't want to use sessions for things like chat messages but you probably could use some type of implementation of queueing using MSMQ.
The approach to chat could be done in many different ways, this is just a suggesting off the top of my head.
Could do a messaging solution in Java Servlets using the application context. Objects stored as attributes in the application context are visible from anywhere in your webapp.
Update: Chat like functionality... I guess that would be AJAX polling your message structure stored in the app context unless you want to use something like applets.
Don't know if it's any good, but there's a chat servlet here that might be useful to use or learn from if you decide to go the Java route...
ASP.NET is "stateless" but it maintains state using Sessions. You can use them by default just using the Session[] keyword.
Look at ASP.NET Session State for some details from Microsoft.