I have the resource uri as /avl/leagues/leagueName. Idea is to delete the league with the provided name in a restfull way. I tried the below but the browsers are always sending a GET instead of the DELETE. Any ideas why? I am using Tomcat on server side.
<form action="/avl/leagues/Cccccc" method="DELETE">
<input type="submit" value="Cancel league">
</form>
HTML forms only officially support GET and POST for submitting.
Typically, people work around that limitation by either sending the request via Ajax, or including a hidden field in the form to tell the server-side code to treat this request as if it were a DELETE rather than a GET. (Of course, the server-side code has to know to look for that field and act accordingly.)
Browsers are not very good restful clients. They basically use POST and GET for forms, and that's all.
The Spring MVC form tag library allows specifying DELETE as the method, IIRC, and will in fact add a hidden field to the form telling the server that, although the method is not really a DELETE (because the browser is not able to send such requests), it should be treated by the server as a DELETE (thanks to a filter). See Using PUT and DELETE methods in Spring MVC for a similar question and its answer.
Related
I am currently learning JSF and was rather amazed and puzzled when I realized that whenever we use <h:form>, the standard behavior of JSF is to always show me the URL of the previous page in the browser, as opposed to the URL of the current page.
I understand that this has to do with the way JSF always posts a form to the same page and then just renders whatever page the controller gives it back to the browser which doesn't know the page location has changed.
It seems like JSF has been around for long enough that there must be a clean, solid way to deal with this. If so, would you mind sharing?
I have found various workarounds, but sadly nothing that seems like a real solid solution.
Simply accept that the URL is misleading.
Append "?faces-redirect=true" to the return value of every bean's action and then
figure out how to replace #RequestScoped with something else (Flash Scopes, CDI conversation, #SessionScoped, ...).
accept to have two HTTP round trips for every user action.
Use some method (e.g. 3rd party library or custom code) to hide the page name in the URL, always using the same generic URL for every page.
If "?faces-redirect=true" is as good as it gets, is there a way do configure an entire application to treat all requests this way?
Indeed, JSF as being a form based application targeted MVC framework submits the POST form to the very same URL as where the page with the <h:form> is been requested form. You can confirm it by looking at the <form action> URL of the generated HTML output. This is in web development terms characterized as postback. A navigation on a postback does by default not cause a new request to the new URL, but instead loads the target page as content of the response. This is indeed confusing when you merely want page-to-page navigation.
Generally, the right approach as to navigation/redirection depends on the business requirements and the idempotence (read: "bookmarkability") of the request (note: for concrete code examples, see the "See also" links below).
If the request is idempotent, just use a GET form/link instead of POST form (i.e. use <a>, <form>, <h:link> or <h:button> instead of <h:form> and <h:commandXxx>).
For example, page-to-page navigation, Google-like search form, etc.
If the request is non-idempotent, just show results conditionally in the same view (i.e. return null or void from action method and make use of e.g. <h:message(s)> and/or rendered).
For example, in-page data entry/edit, multi-step wizard, modal dialog, confirmation form, etc.
If the request is non-idempotent, but the target page is idempotent, just send a redirect after POST (i.e. return outcome with ?faces-redirect=true from action method, or manually invoke ExternalContext#redirect(), or put <redirect/> in legacy XML navigation case).
For example, showing list of all data after successful editing, redirect after login, etc.
Note that pure page-to-page navigation is usually idempotent and this is where many JSF starters fail by abusing command links/buttons for that and then complain afterwards that URLs don't change. Also note that navigation cases are very rarely used in real world applications which are developed with respect to SEO/UX and this is where many JSF tutorials fail by letting the readers believe otherwise.
Also note that using POST is absolutely not "more secure" than GET because the request parameters aren't immediately visible in URL. They are still visible in HTTP request body and still manipulatable. So there's absolutely no reason to prefer POST for idempotent requests for the sake of "security". The real security is in using HTTPS instead of HTTP and checking in business service methods if currently logged-in user is allowed to query entity X, or to manipulate entity X, etc. A decent security framework offers annotations for this.
See also:
What is the difference between redirect and navigation/forward and when to use what?
JSF implicit vs. explicit navigation
What URL to use to link / navigate to other JSF pages
Bookmarkability via View Parameters feature
What can <f:metadata>, <f:viewParam> and <f:viewAction> be used for?
When should I use h:outputLink instead of h:commandLink?
Creating master-detail pages for entities, how to link them and which bean scope to choose
Retaining GET request query string parameters on JSF form submit
Pass an object between #ViewScoped beans without using GET params
Let's assume I have a profile page where DropDown is shown and 1 Admin user can change role of different user.
Eg:
2 - Admin
3 - Member
Assume that 1 is for SuperAdmin. If we have a DropDownList in Asp.Net and bind it to datasource in code behind and then mysteriously try to change values in DropDownList and then submit the form we get exception due to EventValidation. However in Asp.Net MVC if we edit it would definitely because it embraces the web. Is there anything I could do to prevent this kind of cross cutting things in my web applications?
One of thing I could is to check when the form is posted to see if value posted is either 2 or 3 and if not display some message like "Are you trying to hack". Are there any better alternatives?
The solution you mentioned (checking on server) IS the correct solution to prevent such hacks on web sites of any kind.
Using firebug is not the only option to "cheat" javascript based validation. It can also be done with any basic sniffer tools, such as fiddler, which can help a potential hacker to analyze the posted data to ur site, change it in a whatever way he wishes, and then to post it again, using the browser or his own networking tool.
I usually use both the validations (script and server side) in all the scenarios, while the client side validation's main purpose, in my opinion, is to prevent postbacks to server (which will annoy a normal user) when i can already tell on the client side, hes doing something wrong.
Such validations, however, can never be secure enough to guarrante the data is to be automaticlly trusted on server, as its too easy to modify javascript/ posted data, to override them.
EDIT
Following the resposne of UnhandleException:
In MVC specificly, you can use the Data Annotation attributes, to make the mvc engine render client side and server side validation for u
This tutorial explains how do use the attributes validation in ur mvc apps
Do not rely on client side validation. Build a validator for each input. Place the set of validators on the server-side of your application. If there are validators on the client-side, make sure the same validators are implemented on the server-side as well.
Here inputs means URL-based parameters, Form-based parameters, Hidden fields, Cookies ets.
What is proper way to process forms in http?
on /somepage:
<form method="POST" action="/someaction.html">
<input type="text" name="name">
<input type="submit">
</form>
Let's assume, that user didn't filled in "name". So I should produce some error. How should I do it:
First method
POST /someaction and 302 Redirect to /posterror?error=1
GET /posterror?error=1 and 200 Ok with content about errors and form
Second
POST /someaction and 200 Ok with content about errors and form
Third
POST /someaction, remember in session form errors and 302 Redirect to /posterror
GET /posterror and 200 Ok with content about errors and form
Which one is proper way? Maybe some fourth one?
The correct approach is called post/redirect/get and is described by wikipedia as:
Post/Redirect/Get (PRG) is a common design pattern for web developers
to help avoid certain duplicate form submissions and allow user agents
to behave more intuitively with bookmarks and the refresh button.
The third one. It allows the user to safely hit refresh or bookmark the page. The first one, although similar, would require you to pass the content of form back and forth over the wire, which is inefficient. As slight refinements, you might consider:
Redirect back to the form, not to a separate error page, to give the user a chance to correct their error
Rather than just storing the error data in the session, store it with some unique id, and then include that in the redirect url. That way the user can can have the page open in two browser windows and they won't tread one each other's toes.
Expire the stored error after a set length of time, or when the form is finally correctly submitted.
I would suggest having some sort of validation before the for is sent using javascript.
Then of course you should validate the form input on the server side as well. As for whether to use redirects, I don't know of any de facto standard there.
If you want to follow use the HTTP protocol as it was meant you should probably send a 4xx status code back (e.g. 400 bad request) with an informative message saying what was wrong in the input.
Is utilizing client-side validation out of the equation? Using javascript you can avoid posting the form (and reduce server-side processing) and let the client (user's end: browser) perform the validation. What other validations do you have in mind?
Here's a link to basic validation that you can apply using javascript:
http://www.w3schools.com/js/js_form_validation.asp
I'm calling an asp.net webservice from an ASP clasic page basically just with:
<a href='http://domain/webservice.asmx/command'>Command</a>
and when users hit that button it works but they're just shown an xml page. The function will either work or not so I was wondering if it'd be possible to just have a pop up box appear to tell them if it worked or not after they clicked it rather than redirecting them to an xml page.
I'd prefer to not have to use jQuery or another javascript library.
If that's not possible, is there any way to dress up the XML page? Currently it says 'This XML file does not appear to have any style information associated with it. The document tree is shown below.' at the top.
Also, the domain that the webservice is on is different to the domain that the website that's call the webservice is on. Not sure if that matters.
Thanks
Check out this MSDN Link on Calling A WebService From Javascript Using AJAX. No JQuery is required and it boils down to having to use the ScriptService attribute on your WebService method and adding a ServiceReference in a ScriptManager control. You can then easily call your WebService from Javascript and it will call another Javascript function when it finishes. It is in that response function where you can add your confirmation display.
be aware that this is a bad idea to let the user handle directly - web services are almost always called by your code rather than a client browser session. One reason is that raw error information would be hown to the client if there were a problem.
If you really want to do this, you can either:
Use AJAX (No framework required - just JS) or
You can make the webservice non-standard so it returns user-friendly content - perhaps by wrapping it in a website which calls the API behind the scenes and formats the response in a meaningful fashion.
I want to build user friendly error reporting. Wrong input, db connection errors and such.
Problem is i need the same module be implemented for 3 different systems and to use jQuery UI modal boxes for UI.
when i redirect to another page ie.
db connection error i redirect to
error page
when i use return to same page ie.
input value 1 bigger than value 2
when it should be other way around
ASP.NET Ajax UpdatePanel errors,
wrong input for controls within
UpdatePanel that doesn't do regular
postpacks.
thanks for any help with implementation...
To clarify my question
I don't need input or object validation framework. I use ASP.NET and my own business logic to validate on client and server side.
what i really need is
Help with constructing a class that will show errors to users, current process is i catch exception, wrong input value or wrong link and based on that show user friendly message. I have no time and interest in learning logging framework as from my short experience to configure any pre-made high level framework (low level to me is ASP.NET) is harder that to have your own business logic and sometimes requires application re-design...
anyways... My question is pretty clear above. I need way to show centralized messages using jQuery UI.
When i redirect to another page i can save error in Session and get it on other page, if i use return to same page i cannot use Session and had no luck with overriding MasterPage public variables. When i have Ajax UpdatePanel i want again to validate data and show jQuery UI modal...
thats all
A different tactic would be to perform some validation on the client and since you are using jQuery there is a nice form validation plugin called Validation. Here is a good demo page. This will block you post back to the server until you have appropriate data types supplied for you form and will work with your Ajax update panels as well.
With this plugin your HTML mark up is quite straight forward:
<form id="theForm">
<input id="startDate" type="input" class="required datetime"/>
</form>
This will eliminate the need to direct to Error.aspx, store session variables, etc.
For those error that occur on the server, you need to consider whether the user should be able to progress further should a DBConnection error be thrown. In that case you could redirect to your error page, inject your error text and have the client display the content in the jQuery dialog box.
Edit: Are you logging exceptions to a database? If not I would recommend at least a rudimentary log. Other alternatives would be logging to a rolling file appender using log4net. Then, you can load the appropriate error from the logs for display to the user, regardless of how and where you are displaying the error.
See log4net
Also, a not of caution: Don't display DB connection errors to users. Log them so that you know whet is going on and then just tell the user that an error has occurred and that you are aware of it and looking into it.
End Edit
One good way to validate input is to put the validation on your data classes. This allows you to validate them at any time. I know this doesn't solve your redirection scenario which is more of a workflow issue and I hope some others can help you with that.
The reason I mentioned putting input validation on your data classes is that it allows you full control over when your validation is called and it allows you to validate multiple times, on the Client Side and Server Side for example.
A good implementation of this is the FluentValidation framework, which can be extended to automatically generate clientside validation, using the JQuery Validation plugin.
Another option which is becoming popular is Data Annotations. I don't have experience with these yet, but they are worth searching for with your favourite search engine.