is there some kind of standardized way which would allow me to make my ASP.NET MVC web app sessions entirely cookieless, but still keep session support through some standardized hidden form field value on every page (e.g. which would get parsed transparently on every request)?
P.S. I'm not looking for a URL based /(sessionid)/ solution. As stated above, this should preferably be via hidden form field.
A hidden form field would only work if every navigation element on your site is a button which submits the form. This would (among other things) make the back button and refresh awkward and make your site un-spiderable to search engines.
Related
Fairly new to MVC Core and have a View which contains two forms and a single button within one of the form tags. I have a ViewModel so that I can pass multiple objects in and out of the View.
The problem I am seeing is the button only POSTs back the contents of the form it's within and not the data contained within the other form on the same View, even though it populates the ViewModel correctly; I have tested this by putting a button inside each form and depending on which button you have clicked, that form's data is passed back to the Controller.
As a newbie, I assumed that once the property within the ViewModel had been populated the POSTing back of the submit button would capture all entered data - this is not the case.
The examples I have seen seem to pertain to having the requirement for different functions within the same View (eg. Login/Register) but I would like all the data collected to be passed back in one POST, is this possible?
If you want some source, I can submit but I think the above hopefully explains my problem well enough.
TIA.
This is not a problem related to ASP as this runs on your server and generates the html code delivered to the browser. It's the browser who posts back the data ... and hence when a form is submitted, the browser collects the contained input fileds and creates the post request from their data. In fact, the browser doesn't know anything about viewmodels.
You might work around that by generating hidden input fields into each form for the viewmodel's locally unused properties. This way both forms contain all data and the resulting post will be 'complete'. But from my experience, that is ugly to maintain. So I'd recommend you should consider using separate forms with separate post endpoints.
Going with agua's answer although it didn't expressly resolve the issue (if indeed it is solvable).
I want to make a dynamic control on a web page that does an action and generates new HTML code without needing to refresh the page (what would traditionally be handled by JavaScript, I presume). However, my project is currently comfortably and neatly nestled in as a pure ASP.NET Web Pages project strictly using Razor, no MVC at all.
I've hunted everywhere and haven't gotten a clear answer; what answers I have found always concern deep MVC or Web Forms components. As I understand, it should be fairly easy to make use of bits and pieces of those, but I'm still fairly inexperienced with ASP.NET.
What I want to make in short: A button that
Is an image
When clicked, increments a record value (already stored in the Razor code, simple to push to the database), and replaces itself with another image button
This button has a different image, will decrement the record value and replace itself with the original button (they are effectively the inverse of each other)
This is the most complex control I need at the moment for my project, and learning about this will hopefully provide a basis from which to engineer different controls.
The underlying technology of the server is irrelevant, whether it's PHP, ASP.NET, Ruby, et cetera - if you want a web page to "do something", you need to send a request to the server. If you want it to do something without the user directly submitting a form or clicking on a link and changing their location, you have to send the request to your server with javascript. Javascript is how you get the client to do things. The razor templating system operates on the server, not on the client.
Specifically, you should look in to Javascript AJAX requests; I'd particularly recommend learning about jQuery, because it simplifies a lot of aspects of Javascript.
I want to pass data directly from one view to another in the two following situations:
Our users are allowed to dock and undock a toolbar that is persistent thoughout our application. I want this state to be saved when the user navigates to another page. The toolbar is docked and undocked using jQuery.
In some cases, after a successful response from an AJAX call we have a full page refresh or a redirect. We want to display a notification to the user after the refresh / redirect (eg. Your action was successful).
My initial thought was to use cookies, specifically using jquery-cookie, but I was then wondering about using the Session[] variable. Given that our JavaScript will be in an external file I don't know if this is possible and if so does it simply complicate the issue?
Have you looked at Lawnchair?
http://brian.io/lawnchair/
Sounds pretty much like what you need. It is used to persist client side data across pages.
My application required me to store many data elements across views an sessions. Rather than pick a storage mechanism up front (mostly because management couldn't decide) I coded my app using persistence.js.
I was able to pick the precise storage mechanism later with minimal impact to my code.
I faced same type of problem.
after workaround I use a jQuery cookie and store the hidden panel id.
and check the cookie in $(document).ready(function(){}); of jQuery that which panels are hidden and after make their display:none.So after postback the cookies are persist and the panels became hidden.
It solved my problem.
You can do this by simply sending your toolbar state information through hidden fields back and forth ( means from MVC view to controller and than from controller to MVC view ).
I have a simple three page asp.net webforms site and having an issue with the back browser button that throws the popup "...Firefox must send any information that will repeat any action.." when hitting back on the step3.aspx.
The flow is: user lands on step1.aspx, session starts, and a user quotes on a product and gets redirected to step2.aspx. On step2.aspx, you confirm the purchase by clicking an asp:Button. The OnClick event handler, btnPurchase_Click, handles the logic for purchase and redirects, Response.Redirect("step3.aspx"), to step3.aspx. Step3.aspx simply displays the confirmation page (receipt details). The session is destroyed on step3 and when the user hits the back browser button, they are prompted with the resubmit post popup. Ideally, I want the user to hit step1 on hitting back without the resubmit prompt. Each page is set to no-cache and redirects to step1 if session is invalid.
Does anyone have a suggestion for a better flow?
This site will eventually be migrated to asp.net mvc/ajax which will most likely make the PRG workflow easier to implement but for now, looking for a relatively simple way.
A simple solution is to never allow a page to render on postback, but instead accept/store whatever information it was posted, and then redirect to the next page (or itself).
That way if a user hits the back button, it is going back to a GET, not a POST, and avoids the popup.
I give this question a try. The flow you mention will obstruct the pages normal function, which you of course already have in mind. Though, i would say it can be dangerous (against the function you expect) and contraproductive. Based on what I can see from your question, I would definitively remove Page2 and Page3 and keep all logic in same and single page.
I would also be happy to hear what you are trying to avoid, with this? Is it double posts? Like a double-post of a content in a shopping cart? Partial / uncomplete inserts of data input? With the described way to affect back-buttons, you may come around one problem but rise another. A big range of browsers that can act completely different on such work-arounds.
I see two good options,
UserControl,
Create three UserControls which every each of them have each page specific logic. You can programmatically load them into the page. I.e. on bnButton_Click Event. Usercontrols are loaded with LoadControl("PathToAscxFileOnDisk.ascx").
Panels,
I would also think about three <asp:PlaceHolder></asp:PlaceHolder> or perhaps better <asp:Panel></asp:Panel> to put all logic into.
In this case you are completely free from the postback issues and can focus on moving your functions into business logic and have use the Code-File to control the flow on show/hide and populate the controls in/out from the panels/usercontrols. You can probably also control the postback / click-URL & push-enter-key.
And you mentioned Ajax,
Ajax is absolutely there to make your page stateless (which means you can work without cache, sessions, viewstate and so on. Though, the problem lies in the users possibility to navigate between pages. I would think even Ajax is of less help, while you keep the three-pages-solution.
I would personally say it is a simple task to move the aspx files into each ascx and create a aspx as a master-container. With that option you even avoid duplicate namings (like if you copy / paste the code into panels) and trouble with Page_Load flow/logic.
If I understand correctly you're not yet using the PRG.
On step 2, temporarily store the information and redirect to show it. How you do so depends a lot on your application: session, database, cookies, etc are all options with different caracteristics.
Then redirect to show that information.
Same goes on step 3.
If you hit back on step 3, you'll go to step 2. But given you're going back to a GET request, there won't be a warning. Like you said, your application destroys the session data on 3, so according to what you said the user would go to step3.
Maybe I'm missing something on what you said.
When we use asp.net pages we can navigate from one page to another via more than one method.
This issue becomes more comlicated when you want to keep the history of current user navigation.
Lets say we have a form. The user will start to fill it, by adding values to one or more fields, but on my case he can create a navigation to another page before we posting-back the current page and thats ofcourse couses the controls to loose its values.
How can i keep the controls states through postbacks between asp.net pages.
Should i use the SessionState or maybe cache it for each user?
thanx
You pretty much have the choice of session state, cookies, or home grown state maintenance using a database. I typically get around this by combining all my pages into separate panels within a single .aspx. That way I can use object persistence and viewstate. Rather than navigating from page to page, I merely have to toggle the .visible property of different panels depending on my users' navigation choices.
RO
The answer mostly different in different application types. For example if you plan that your application will have a lot of people storing in session become an expensive operation, but for small applications it work good.
In all cases you can create some mechanism that will store temporary entered data into database, this approach will work everywhere, but it's slowly than in memory cache.
To give correct advice please explain a bit more about your application.
You could use Session variables or the ASP.NET Cache object to store state so that the user can resume filling in the form after navigating away from the page. However, if the issue is that the data entry is a lengthy process that the user may wish to pause and resume at a later time, give them the option to save their current progress to a database. If the user attempts to navigate away from the page, remind them that they may lose their current work and give them the option to save it.