I want to post some data to the server, and in response, I want to create a CSV file, with application/excel as the MIME Type (recently recognized as Internet Media Type), to force the browser to open the generated CSV file in Microsoft Excel. However, I also want to prevent user from re-submitting the same info (re-posting the form) by any accident as the result of refreshing the page.
With simple CRUD operations, I use Post/Redirect/Get pattern, so that any further refreshing will only send HTTP Get Request to the server, without any parameter, thus not changing server's state (Idempotence).
What is the recognized pattern for stopping user from re-submitting (re-posting) the same info to the server, when the response is not a page, but a file?
Any idea?
The Post/Redirect/Get pattern is an answer to a browsing event.
Here, there is no browsing action (the form submission only open a 3rd party app, i.e excel), and so any kind of browsing related pattern will be useless.
I suggest you use both a server side trace of the initial submission (with a unique token maybe), so you can prevent the file generation, and an easy to write client side script like <form onsubmit="this.onsubmit = function(){ return false ; }">
I can offer you one other solution.
Take hash (MD5/SHA256 ..) of your submitted data. The hash will be [fairly] unique.
Put it in list in a session with a time limit, say 5 minutes.
Even your user submit same data. Hash will be same and you can give error message to your user.
If different users can post same data, you can also hold user information in the list. And give error message according to user.
Related
I want to upload some XML files to Alfresco, so the create con tent form has an input file form element.
I need to check if the XML is well-formed, and I already have the backend validation functions triggered on ResourceBehavior.onContentUpdate. If the XML is malformed, I want to notify the user with a dialog window.
So far, I can prevent the user to submit malformed XML by throwing an exception when the XML is malformed, but I can't figure out how to have share to display an error message.
I have been looking at all the validation JS in share, but remember, file input forms need to be submitted first so that you can have a look at its content, thus the validation has to be server-sided.
Any pointers on where should I begin?
The problem you are going to have is that your backend behaviour is not aware of the specific client session that made the changes and what client session it is that needs to be notified.
If you want to display a useful message then you are going to have to write some additional Share customisation. Some options which you can explore are having an action or webscript that returns whether the XML is valid or not and customising the Share upload form to execute this action/webscript after the file has been uploaded and then return the relevant message to the user.
You'll find a pretty detailed post on modifying the upload form here:
http://www.ixxus.com/blog/2011/09/customising-upload-files-dialog-alfresco-share
If you're feeling lazy then I'd consider just aborting the file creation if the XML is invalid during an onCreate behaviour and then the user will see an 'Internal Error'.
I'm pretty new to web programming. The whole project links two shops together.
One of our customer's who owns the first shob has provided some sort of an Event API which sends a request to one of our simple html/js files when an event occurs (different ones are specified - e.g. a new customer was created which needs to be synchronised between the shop databases). Included in his GET request is an URL as parameter.
We have to parse this given URL, sending a request to this URL and "reading" what the actual content of the event is (name of the new customer etc.), writing it into our database and giving a reponse to the initial request from the other shop (sucess or failure).
How can I do this in a simple way in an html/js file without setting up web services etc.? Don't bother about the database actions, its taken care of .. its about the automatic redirecting ..
Many Thx ..
J
I am working on existing code that uses CGI::FormBuilder, and I've gone through all of the documentation to see how this might work, and I'm not 100% convinced that it will. The code has several free-form fields and 3 buttons: Update, Cancel and Test. The test button sends an email using settings entered into the fields.
In the JS for the form, I use an ajax call when "Test" is clicked so that the perl code in the form executes. The update and cancel buttons return like the form is supposed to when it is submitted. The reason for this is that when the test email is sent, I don't want the user to be taken to a returned page, but remain on the form with the values intact, so that if the values are correct, the user does not have to re-enter them when they want to update the actual values (which updates the values in my DB). Apparently, since the form isn't being "submitted," the values that it attempts to use on this "test" are the values loaded into the form with the page opens - it isn't using the values the user input before hitting the test button. Is there a way to make this happen?
Long question short: with CGI::FormBuilder, can I get the values currently in the fields via PERL without submitting the page? Thanks!
Short answer: yes.
Medium answer: Yes. You can use javascript in the page to send information to your server side application.
Long answer:
You seem to have some confusion about how server and client side code interact with webpages. This is pretty common. Many people expect their to be some kind of communication between the rendered page and the program that generated it. AJAX and related technologies blur the lines here and make things more confusing.
Here's a timeline of a simple, old-school CGI form:
Client requests page. Server receives page request. Server dispatches
to CGI script.
Server executes CGI script.
Server sends result of CGI script to client.
Client renders script results.
User fills out form.
User clicks "Submit". Client requests page with parameter information (details vary with type of request, form configuration).'
Server receives page request.
Server dispatches to CGI script.
Server executes CGI script. Server sends result of CGI script to client.
Client renders script results.
Each message from the Client is handled separately.
AJAX lets you send messages to the server and get the response without clearing the currently loaded page.
So, just throw some javascript code into the html, and set up an onModify handler that will make an AJAX request and pass data back to the server. The AJAX request is just another HTTP request, just like those above, but it runs in the backgound. All you need to do is catch the submitted data and respond. Your javascript needs to catch the response and do something with it.
Answer to the short question is "No".
Answer to the long question is "Yes".
All you need to have two "Submit" buttons: "Submit" and "Test".
The submit by Test will send form to the CGI and CGI will only validate the fields' values and render same form with same values back and message if there is an error in fields.
The question is generally language/framework agnostic but if it matters I work with Grails and most interested in grails specific solution if such exists.
There's a form mapped to URL: /foo/create. When user type in this URL to his browser the form is shown.
Form action attribute directs to /foo/save and has method POST. If saving is successful, then standard post-redirect-get pattern is applied, and user is redirected to /foo/show.
But, if user specified incorrect data, they should see the same form again with error messages and all their data preserved. To implement this behavior, I do forward to the controller which produces the form (the same is mapped to /foo/create).
After that user sees the form with data and error messages, but URL field is changed in browser to /foo/save. And if user change focus to URL field and press enter - 404 will be shown (because nothing is mapped to /foo/save + method=GET pair).
The long story short: URL /foo/save is shown in a browser (as there were no redirection after form was submitted) but it directs to nowhere if accessed by HTTP GET method.
How to deal with this situation? Surely, I can map something to /foo/save but I wonder if there's a way not to change URL shown in a browser after form with wrong data was submitted?
Two approaches:
The form submits to itself, i.e. /foo/create submits to /foo/create, only if successful the page is redirected to /foo/show. This should use a post-redirect-get cycle as well and store the submitted data in the session, but could be a simple POST without redirect.
/foo/save always redirects again, either to /foo/create if the data was invalid or to /foo/show if the data was valid. This will always use a post-redirect-get cycle with the data saved in the session.
I'm writing a Catalyst application that's required to have a fairly short session expiration (15 minutes). I'm using the standard Catalyst framework authentication modules, so the user data is stored in the session -- i.e., when your session expires, you get logged out.
Many of the uses of this application will require >15 minutes to complete, so users will frequently submit a form only to find their session state is gone and they're required to log back in.
If this happens I want to preserve the original form submission, and if they log in successfully, continue on and carry out the form submission just as if the session had not expired.
I've got the authentication stuff being handled by an auto() method in the controller -- if you request an action that requires authentication and you're not currently logged in, you get redirected to the login() method, which displays the login form and then processes it once it's submitted. It seems like it should be possible to store the request and any form parameters when the auto method redirects to the login(), and then pull them back out if the login() succeeds -- but I'm not entirely sure of the best way to grab or store this information in a generic/standard/reusable way. (I'm figuring on storing it in the session and then deleting it once it's pulled back out; if that seems like a bad idea, that's something else to address.)
Is there a standard "best practices" or cookbook way to do this?
(One wrinkle: these forms are being submitted via POST.)
I can't help thinking that there's a fundamental flaw in mandating a 15 minute timeout in an app that routinely requires >15 minutes between actions.
Be that as it may, I would look at over-riding the Catalyst::Plugin::Session->delete_session method so that any contents of $c->request->body_parameters are serialised and saved (presumably to the database) for later recovery. You would probably want some rudimentary check of the POST arguments to ensure they're what you're expecting.
Similarly, create_session needs to take responsibility for pulling this data back out of the database and making it available to the original form action.
It does seem like a messy situation, and I'm inclined to repeat my first sentence...
UPDATE:
Whether you use delete_session or auto, the paradoxical issue remains: you can't store this info in the session because the time-out event will destroy the session. You've got to store it somewhere more permanent so it survives the session re-initialization. Catalyst::Plugin::Session itself is using Storable, and you should be able to with something along these lines:
use Storable;
...
sub auto {
...
unless (...) { #ie don't do this if processing the login action
my $formitems = freeze $c->request->body_parameters;
my $freezer = $rs->update_or_create(
{user => $c->user, formitems => $formitems} );
# Don't quote me on the exact syntax, I don't use DBIx::Class
}
...
my $formitems = $c->request->body_parameters
|| thaw $rs->find({$user => $c->user})->formitems
|| {} ;
# use formitems instead of $c->request->body_parameters from here on in
The underlying table probably has (user CHAR(x), formitems TEXT) or similar. Perhaps a timestamp so that nothing too stale gets recovered. You might also want to store the action you were processing, to be sure the retrieved form items belong to the right form. You know the issues for your app better than me.
I would store the form data as some sort of per user data in the model.
Catalyst::Plugin::Session::PerUser is one way of doing that (albeit somewhat hackishly). I would reccomend using the session plugin only for authentication and storing all the state info in the model that stores your user data instead.
And I totally agree with RET's opinion that the 15 minute limit seems really counter productive in this context.
I came across this whilst searching CPAN for something entirely unrelated.
Catalyst::Plugin::Wizard purports to do exactly what you need. The documentation suggests it can redirect to a login page whilst retaining the state of the previous action.
NB: I haven't used it, so can't vouch for its effectiveness.
In the end, we ended up grabbing the pending request (URL+params) in the auto(), serializing and encrypting it, and passing it via a hidden form element on the login page. If we got a login request with the hidden element populated, we decrypted and deserialized it and then redirected appropriately (making sure to pass through the standard "can this user do this thing" code paths).
You could always have some javascript on the client that keeps the session from expiring by making a small request every few minutes.
Or you could have AJAX check for an active session before posting the form and presenting the user with a new login box at that time if needed.