I have the following problem
I have a web framework built with classic asp that saves the page state in hidden textboxes, and then issues a submit to itself.
Before submitting, we have a javascript functions that saves the action in a hidden "action" input, and then performs the submit.
The page loads the state from those hidden texts, reads the action issued, reads extra parameters, like the id of the record to edit, and then builds the page accordingly.
I'd like to make a url link to automatically start the page with "edit" action on a "x" id.
So I was thinking about building the following url, for example
http://myapp/user?action=edit&id=23
the problem is that when the page auto-submits, que url string keeps the parameters.
I'd like to achieve the following:
when the user clicks on
http://myapp/user?action=edit&id=23
my page should receive the posted values action=edit and id=23
but the url should be just http://myapp/user
and both parameters should be kept in the hidden texts... (I wonder if I make myself clear...)
thanks a lot
saludos
sas
ps: I have a couple of ideas about how to solve it, but I'll post them as answers...
The first solution that came to my mind was to save the values in the session, issue a redirect without the parameters, and then load the parameters and remove them from the session...
the other solution, and the easiest one to implement, is that whenever I read parameters I first read them from the querystring (request.queryString) and then overwerite them from the posted values (request.form)
that way I wouldn't care if the parameters from the querystring keep being sent, the only problem left would be the annoying url...
Related
I have page where users can select from one or more images. When they are done I would like them to navigate to the next page and what is displayed would be based on the selection from the previous page.
"Selecting" just means that they click the image and it has a CSS class added to it. When they click the link to navigate to the next page I'd like to collect the images that have been selected and pass that information along using either TempData or Session.
In most of the examples I have seen either inputs or the query string is used to pass information from the View to the Controller. How can I pass which elements have a particular class to my controller when a link is clicked?
If you're using a link click, I'd probably just append the selected images to the query string. I'm assuming you don't mind exposing this query string to end users.
I'm sure that's probably not the answer you were looking for. But as you stated I think you're only to legitimate options are passing the values through the query string or using hidden inputs and posting the page to your action by intercepting the link click event.
You said you do not want to post back to servers. You cannot access TempData or Session without posting back to server, so they are out of scope.
You only have client side option, so you want to collect a user's selected items in array.
Once the user clicks to Next Page, you create a query string like this ?ids=1-2-3-4 and retrieve those value at next page.
Other thoughts: Long URL likes this is a bit ugly, and URL has maximum length limit depending on browser. If I'm you, I'll post back to server to collect the selected values. Then use TempData (or some persistent storage).
I have a heap of entities that are keyed by ID. In one screen I load a "Subject" based on the ID like so: "/Results/Subject/53" On that same screen I have a combo box that maintains a list of all subjects. The user can change the selection in this combo to another subject and I load the results for that subject using ajax. When I do this the URL in the browser is stale as I might be now be looking at /Results/Subject/45 If a user reloads I reload the original document and not the new one.
I would either like to update the URL (which sounds hacky as) or I would like to base my navigation on something else besides the Id as part of the URL. How can I do this? How can I load controllers for specific items without specifying the Id as part of the URL.
You can also pass the id via the HTTP GET parameter: /Results/Subject?id=45 or HTTP POST parameter.
However, I doubt that this will answer your question.
A colleague of mine has encountered the similar problem, and he solved it by altering the browser URL string (by attaching a specific #anchor to it).
Easiest way would be to ditch the ajax when that drop-down changes, and just navigate to a new url (/Results/Subject/NewID).
If you want to keep the ajax, you could just put the key at the end of the url with a # like "/Results/Subject#53", then load it via Ajax (the #53 will not be passed over to the server). That way, when the user changes the drop-down, you can navigate to "/Results/Subject#NewID" without it reloading the page.
I want to redirect the user to another page to fill out a captcha but i would like to keep the post data, and if the captcha pass to send it 'back' and complete the previous page action.
When/if the user succeeds i like to add an captchaPass=true and would like access the post data and continue processing. Right now i am using redirects but ATM i am not required to use it.
Is it possible to carry the post data? keep in mind i may the user access multiple pages so separating data and not having a mixup is necessary.
One idea is to get and save all posted data [1] on the captcha page, and then recreate a middle white page with this form data and automatically make a new post to the previous page.
Can this work with out any issues with hash checks and security ?
Is there a better idea with out this white redirect page ?
[1] One other issue here, how to send this posted data with the redirect ? and not change the url - or make it too big to accept it. Keep in mine that a server transfer may not good idea because is complicate the thinks on captach post back.
Update 1
The basic idea here is how some one capture the full post back of a page, show a different one page and then send the post back data to the original first one.
The reason is to stop a bad user, or an attacker bot program that try to bring down the pages/server by making many post back from different pages in short time. All that happens with out javascript, and most attackers use custom made programs that just make post of data to all page together try to bring down the system.
For example, if a page have a search box, is very easy for most of the the site to bring them down by start making hundred of random search with wildcard (called and Dos Attacks using SQL wildcards) and make the sql server and the computer spend his time and cpu to search and search thinks. So to prevent an attack like this you need to recognize multiple post backs from the same computer, and then the next step is to redirect him to a captcha page to block him out in case that is a computer program.
Other example, many page have email submit, very easy you can submit hundred times the email of his and full his mail box in no time with hundred of emails, or on a store to place all items on the cart again and again and full the database with stuff like that.
So ajax and javascript is not working in this case, and we need a way to redirect him after the post back to a page that can check if is a real user or an attacker and stop him - but if is a real user must return back to his normal action.
Update 2
This all must be done in a general way, eg on BasePage, or on Global.asax or somewhere that is independed from the content of any page. Because we try to prevent a DoS attack, or multiple submit anywhere on any random place of any random page.
Yes I know how you can place a captcha on the contact page, but this is not what this question was first asked for - this questions asked how can carry post data to one different page, keep them there and then resend them back to the original one.
The obvious solution is to read all post back, and save them on the form, and then read them back and make on fly a form only with that data and make the post back. Here I am asking if there are any other better than this solution.
Other Applications
There is also the case that a user is inside a page that request authentication, but the authentication ticket has expired, and the user make post back. In this case we need to keep somewhere all the posted back data, to proceed with the login page, and resend them back to the first page that request the authentication.
Sure, just write the form data out to the captcha page in hidden elements with the additional captcha fields added to the form. Have your submit action post the whole thing back to the original. Using ASP.NET it's probably easier to have the captcha written to the same page with the form fields hidden, but you can do cross-page postbacks as I've described above.
Cross Page Posting might help you.
Why not implement the CAPTCHA with AJAX? Load the captcha object and form with Javascript in a div perhaps displayed lightbox style, accept the user input and post it to your server for validation, hence continue with the users post request or keep them there until they get it right (or cancel).
A more specific situation example:
Give the form submittal button an onClientClick value of some Javascript function. This function decides if this particular form needs a CAPTCHA. If it does it loads an interface for taking the CAPTCHA (which you'd need to do with some server-side code) and inserts the CAPTCHA's input element to the form that the user clicked to submit.
Once the user has entered the CAPTCHA input and clicks some button whose click event is bound to return to your first JS function, the Javascript intercepts this action and posts the full form, all the data from the original form and the CAPTCHA for validation. Your server script can now process all this at once!
This is the best solution I can think of that works similar to how you've asked, but I can't imagine why you want to perform the CAPTCHA on a different page.
Server.Transfer with MultiViews, Panels like control is fine with you? In this way, no need to bother about the Data Maintenance and Postbacks. You can do the validations in javascript.
You can keep both functionality in the same page to avoid moving data from one page to another page/Bring the data back to original page. You can utilize Session for this intermediate operation. Set it back to associated controls across Postback. You can create a class, Instantiate it and Initialize the control values in this class object. Save class object in Session. On Postback, You can reassign the values to the associated controls. This will definitely keep the things simple and without much complexity.
Doubts ?
From reading here and around the net, I'm close to assuming the answer is "no", but...
Let's say I have an ASP.Net page that sometimes has a query string parameter. If the page has the query string parameter, I want to strip it off before, during, or after postback. The page already has a lot of client-side script (pure JavaScript and jQuery).
As an example, say I load:
http://myPage.aspx?QS=ABC
The QS parameter is necessary to control what appears on the page when it first loads and is set by the page that "calls" it. myPage.aspx has form elements that need to be filled in and has a submit button that does a postback. When the page completes the postback, I need to returned URL to be:
http://myPage.aspx
in order to avoid the client-side code that is called when the query string is present. In other words, after a submit I don't want the client side actions associated with the query string parameter to fire. I know I could append the form contents to the URL as query string parameters themselves and just redirect to the new URL and avoid the submit/postback, but that will require a lot more type checking on the codebehind to avoid bad data and casual spoofing. I supposed I could also set a hidden field in the codebehind and look at it along with the query string to cancel the client-side behavior if I am coming back from the postback, but that still leaves the query string intact basically forever and I want to get rid of it after the initial page load.
Any ideas or best practices?
PS - Is there anything I can do with the Form.Action property that won't break the postback behavior?
I would use an HTTPModule to intercept and rewrite the URL and query as it came in. I'm not 100%, but I don't believe this has any impact with viewstate.
It sounds (and looks) complex, but it's actually fairly trivial and open to a ton of refinement and extension (as per .NET in general).
iam not sure this is what you are looking for, but if understand correctly you could do this:
-on page load check for the QS value, if its not there use a hidden input field.
-first time page loads with QS, do your normal processing and store QS value in a hidden input field.
-if no QS then use the hidden input value
-after postback, you could redirect to the same page, at that point you could user Request.Form[] to retrieve the hidden input field, still load the data properly but get rid of the QS.
it made sense in my head, i am not sure it make sense now, but i'll let you decide.
It is probably bad practice, but in those cases (and ones I just need to 'reset' the page), I simply do a Response.Redirect to the same page.
I have written an application in ASP.net, that is designed to let the user add records to a database. The page is set up that when a user adds a record, the ID number of the newly added record is set in session, the page Response.Redirects to a "Thank you for submitting" page, then redirects back to the original page to allow further edits. Users can also use the Back button on this screen to go back to the original record adding page, which allows them to make edits to the data.
However, I have found that storing the ID in session isn't a terribly good solution, as a user might try to create two documents in different tabs or windows. I have also tried setting the ID in a literal control, but this causes the problem that when the user uses the Back button, the literal control isn't set to the ID, and new records get added instead of one being edited.
Is there any kind of solution for this?
I'd recommend storing your ID in the QueryString. After the record is added, redirect to your "thankyou" page, which then I am guessing contains a link to the edit form which you will generate with the ID in the querystring. When that link is followed, the edit page shouild pull the ID out of the query string in order to load up the correct record to edit.
Your add and edit form can even be the same page, when an ID is provided in the querystring, your form knows to edit that record, otherwise your form adds a new record.
Silly question, why can the user use the back button to edit the data just accepted in a post?
If the edit previously posted data is a common scenario why not just redirect to a page when the data is accepted that lets them edit it. Then if the hit the back button they would be going back to the original "clean" insert/add new data page.
This would give the following flows
Add->[Post]->Edit->.....
Add->[Post]->Edit->[Back button]->Add->[Post]->Edit->[Post]->Edit....
Have you tried adding the ID in the querystring? Then you could read it, and add it to the session as needed (say on a user clicking the back button).
Seems like a lot of problems allowing editing of an object in a page rendered when using the back button. Would it be too much to give them an edit button instead?
The controls save their state in the ViewState. If you choose to use SessionState instead of ViewState to store the information, then the controls will save their state in the session state and it won't work properly with multiple tabs.
I have not yet found a way to bypass this issue while still using SessionState. Our solution was to use the normal ViewState.
I've tried storing the ID in the querystring (which is mostly fine for editing), but the problem with that is when the information is stored in session for when they use the Back button. If the user does the following:
User creates a record (1st record), the ID is passed along in the querystring, and temporarily stored in session.
User creates another record (2nd record), the ID is passed along in the querystring, temporarily stored in session.
User uses the Back button on the first record to go to the page that doesn't have the querystring.
It's probably a far-fetched scenario, but it's one that may happen. The only solution I have is to block the usage of the Back button to go back to the adding page, by using window.history.forward() in JavaScript. But this as a solution is terrible.
My question for you is why are you storing anything in the session to begin with? If you can avoid storing anything in the session, I think you will be better off altogether.
Having thought about this, does the following sound like a decent solution to the problem I outlined above?
When first adding a record, store a timestamp of when the add page was accessed in a hidden field.
This timestamp is passed through session when the user clicks save. Along with the ID.
If the user opens another tab at the same time and saves, then the new page's timestamp gets passed through session.
If the user tries to access the add page of first record (using the back button), the system looks up session, and sees if there is a timestamp, and whether it matches the one in the hidden field for that page.
If it doesn't match, then the user gets a prompt, and told to edit the record properly.
Does this sound reasonable, or too overly complex?