I am a beginner of Prettyfaces, so please forgive me if I missed something really basic.
My url-mapping contains a EL-injected path parameter. The parameter value could be changed by user through selecting a drop down list item.
My question is: since it's an ajax call, the view id didn't change, so if I bookmark the url, the value still contains the original parameter value instead of the user update one. How do I get the browser addressbar url updated based on user's action?
There are two solutions here. You can respond to the AJAX request with a 302 Temporary Redirect, e.g: response.sendRedirect("/new/location") - usually done through JSF navigation.
Or, when the AJAX response comes back, you can use the JavaScript HTML5 push-state history API (if the browser supports it) to update the address directly: Good tutorial for using HTML5 History API (Pushstate?)
Related
So I am trying to find the most direct point to do a 'Get' from an API when a page loads. As an example, if in my app I go to "#/somepage", when I click on the link to do so, it also does a get from "http://{{host}}/api/common/trans/claim". That URI contains a single property with no name that looks like " "Bzc5YUL7dNjK6ApxpNK1XB%2bDtTU8cw7xRSGpjZ4XRuE%3d" ". So if I fire or add some listen event to this, what is the best way to store? I know that might be a seperate question, but legitimate here because of how the data is returned. Hopefully I provided and storied my question correctly.
My queries have pointed to things like viewContentLoaded and DOM readiness, etc..., but those seem overkill for this when simply clicking a link an retrieving info from the API.
Keep in mind, this API is local and private and the URI data is only available until after the user is logged in.
I'm not if I follow your question but you can fire the function using the ng-click directive.
To store the return value you could set it to the $scope of your controller or save it to a service if you'd like to share the data across controllers.
Say I have a servlet that processes form data and returns a web page. Is it possible to store the web page that is returned on the server so that it can be accessed again without filling out the form?
I think its possible. But mostly it will be possible if the form submitted generated a unique page with unique URL.
Like let say when u submit a form and if it created a URL like
'http://example.com/result1.html'
then we can use the Expiration filter to set the Expiration HTTP header and make it cacheable.
But one change is that the caching has to be done by a separate caching server and i hope tomcat cannot do it by itself.
One possible way is -
You save the form object along with a unique url generated as key pair value. so key will be your unique url and value will be the form object which you have to display on the page and you got what you want.
Few more hint -
To generate unique url suppose your result page is 'http://example.com/result.html' you can add a auto increment number like 'http://example.com/result1.html' managed programatically. or you can also thing about UUID class available in java.
I understand that deleting data with an http GET is a security hole. Is it also the case that calling delete from a link in general is a bad idea? I'm referring specifically to an asp.net mvc actionlink that specifies the http method as a POST.
#Ajax.ActionLink("Delete",
"DeleteNote", new { noteid = Model.noteid },
new AjaxOptions
{
Confirm = "Delete?",
HttpMethod = "POST",
OnSuccess = "postmessage('note_Deleted_" + Model.noteid + "')"
})
Using HTTP GET is not a security hole, but could be considered bad design for a RESTful API. The convention is to use HTTP DELETE for deletion of resources. The security hole is if your API does not support any authentication/authorization, whether it is a GET, DELETE, POST or PUT. Then anybody with a web browser or tool like Fiddler could manipulate data they should not have access to. Take a look at this article that describes how to use a customized Authorize attribute to secure a Web API.
You can still use a link to invoke your API but do not use a direct link that defines an href to the URL for delete. Instead define your anchor like this with an id.
Delete
Then define a click event that calls a Javascript function that makes a secure ajax call to your API as described in the previously mentioned article.
$('aDeleteNote').click(DeleteNoteFunc);
If you want to use Razor to specify the noteid used to identify what to delete then you can put it in a hidden field our a Javascript variable that the DeleteNoteFunc has access to.
What you're touching on here is a vulnerability called Cross Site Request Forgery.
A quick example of this would be as follows.
You have a GET link on your website, e.g. "www.example.com/notes/delete/232"
A user is logged into your website with permissions to delete note 232.
The user receives an email from the attacker that entices them to visit the attacker's website.
The user visits the website in the email, but one of the image tags is defined as follows: "<img src="http://www.example.com/notes/delete/232" width="0" height="0" />"
This causes the browser to make a HTTP request to your website, sending the correct authentication cookies which will result in the note being deleted without the user's knowledge.
Now this is not a vulnerability in the GET itself, but it is one of the reasons why methods such as GET should not be used to make changes on the server.
Yes you are correct you should use POST for this. POST would still be vulnerable to an attack similar to the above but the attacker would either need to create a standard HTML form to POST the data, or would have to create the POST via AJAX. If you pass the HTTP header "X-Requested-With: XMLHttpRequest" and check this in your server method this will help prevent this attack as this header cannot be added to a cross domain request.
If you want to further secure this then you should implement the Synchroniser Token Pattern which will validate a token as part of the POST request to ensure the request came from your own site.
I don't know if I'd describe deleting data from a GET request as necessarily a security hole (provided your application implements proper security), but it's often not a great idea as you know.
If you have delete links, you should definitely put nofollow on them, but I don't think that links which delete data are inherently bad. Even if you have no link in your markup, you still end up making an http request to a url that will delete something, either through a form submission or ajax.
I want to make a turn based game (Something like Checkers) with the help of Servlets and jsp pages.I created a page that has a newGame button that redircet to the gamePage(It redirect the first into a Black.jsp and the other request will be redirected to Red.jsp).
My problem is ,how could I refresh the other jsp automaticaly if one of them changed.
Note:After the change in one of the jsp it redirect the request to servlet and servlet update the changed jsp graphics.but the other jsp stay inactive.I want to make it active.
Thank You
It sounds like what you need is Comet. Here's an overview of how it works.
http://www.ibm.com/developerworks/web/library/wa-cometjava/
Basically, the "other" user's browser will send a request to a servlet to get an update, but that request won't receive receive its response until the current player makes a move. This gets around the problem posed by the fact that, with traditional HTTP, the browser always has to be the one sending the request to the server, it can't be the other way around.
There are some variations on the technique. Now that you know the name, I'm sure you'll be able to find lots of useful information about it.
There's another technology called WebSocket which can also serve this purpose, but it requires additional capability built into the browser and, as of now, probably not all of your users will be using compatible browsers.
Even if I offer alternatives to PUT and DELETE (c.f. "Low REST"), how can I provide user-friendly form validation for users who access my web service from the browser, while still exposing RESTful URIs? The form validation problem (described below) is my current quandry, but the broader question I want to ask is: if I go down the path of trying to provide both a RESTful public interface and a non-javascript HTML interface, is it going to make life easier or harder? Do they play together at all?
In theory, it should be merely a matter of varying the output format. A machine can query the URL "/people", and get a list of people in XML. A human user can point their browser at the same URL, and get a pretty HTML response instead. (I'm using the URL examples from the microformats wiki, which seem fairly reasonable).
Creating a new person resource is done with a POST request to the "/people" URL. To achieve this, the human user can first visit "/people/new", which returns a static HTML form for creating the resource. The form has method=POST and action="/people". That will work fine if the user's input is valid, but what if we do validation on the server side and discover an error? The friendly thing would be to return the form, populated with the data the user just entered, plus an error message so that they can fix the problem and resubmit. But we can't return that output directly from a POST to "/people" or it breaks our URL system, and if we redirect the user back to the "/people/new" form then there is no way to report the error and repopulate the form (unless we store the data to session state, which would be even less RESTful).
With javascript, things would be much easier. Just do the POST in the background, and if it fails then display the error at the top of the form. But I want the app to degrade gracefully when javascript support isn't available. At the moment, I'm led to conclude that a non-trivial web app cannot implement an HTML interface without javascript, and use a conventional RESTful URL scheme (such as that described on the microformats wiki). If I'm wrong, please tell me so!
Related questions on Stack Overflow (neither of which deal with form validation):
How to send HTML form RESTfully?
How do you implement resource "edit" forms in a RESTful way?
you could have the html form post directly to /people/new. If the validation fails, rerender the edit form with the appropriate information. If it succeeds, forward the user to the new URL. This would be consistent with the REST architecture as I understand it.
I saw you comment to Monis Iqbal, and I have to admit I don't know what you mean by "non-RESTful URLS". The only thing the REST architecture asks from a URL is that it be opaque, and that it be uniquely paired to a resource. REST doesn't care what it looks like, what's in it, how slashes or used, how many are used, or anything like that. The visible design of the URL is up to you and REST has no bearing.
Thanks for the responses. They have freed my mind a bit, and so in response to my own question I would like to propose an alternative set of RESTful URL conventions which actually embrace the two methods (GET and POST) of the non-AJAX world, instead of trying to work around them.
Edit: As commenters have pointed out, these "conventions" should not be part of the RESTful API itself. On the other hand, internal conventions are useful because they make the server-side implementation more consistent and hence easier for developers to understand and maintain. RESTful clients, however, should treat the URLs as opaque, and always obtain them as hyperlinks, never by constructing URLs themselves.
GET /people
return a list of all records
GET /people/new
return a form for adding a new record
POST /people/new
create a new record
(for an HTML client, return the form again if the input is invalid, otherwise redirect to the new resource)
GET /people/1
return the first record
GET /people/1/edit
return a form for editing the first record
POST /people/1/edit
update the first record
GET /people/1/delete
return a form for deleting the record
(may be simply a confirmation - are you sure you want to delete?)
POST /people/1/delete
delete the record
There is a pattern here: GET on a resource, e.g. "/people/1", returns the record itself. GET on resource+operation returns an HTML form, e.g. "/people/1/edit". POST on resource+operation actually executes the operation.
Perhaps this is not quite so elegant as using additional HTTP verbs (PUT and DELETE), but these URLs should work well with vanilla HTML forms. They should also be pretty self-explanatory to a human user...I'm a believer in the idea that "the URL is part of the UI" for users accessing the web server via a browser.
P.S. Let me explain how I would do the deletes. The "/people/1" view will have a link to "/people/1/delete", with an onclick javascript handler. With javascript enabled, the click is intercepted and a confirmation box presented to the user. If they confirm the delete, a POST is sent, deleting the record immediately. But if javascript is disabled, clicking the link will instead send a GET request, which returns a delete confirmation form from the server, and that form sends the POST to perform the delete. Thus, javascript improves the user experience (faster response), but without it the website degrades gracefully.
Why do you want to create a second "API" using XML?
Your HTML contains the data your user needs to see. HTML is relatively easy to parse. The class attribute can be used to add semantics as microformats do. Your HTML contains forms and links to be able to access all of the functionality of your application.
Why would you create another interface that delivers completely semantic free application/xml that will likely contain no hypermedia links so that you now have to hard code urls into your client, creating nasty coupling?
If you can get your application working using HTML in a web browser without needing to store session state, then you already have a RESTful API. Don't kill yourself trying to design a bunch of URLs that corresponds to someone's idea of a standard.
Here is a quote from Roy Fielding,
A REST API must not define fixed
resource names or hierarchies
I know this flies in the face of probably almost every example of REST that you have seen but that is because they are all wrong. I know I am starting to sound like a religious zealot, but it kills me to see people struggling to design RESTful API's when they are starting off on completely the wrong foot.
Listen to Breton when he says "REST doesn't care what [the url] looks like" and #Wahnfrieden will be along soon to tell you the same thing. That microformats page is horrible advice for someone trying to do REST. I'm not saying it is horrible advice for someone creating some other kind of HTTP API, just not a RESTful one.
Why not use AJAX to do the work on the client side and if javascript is disabled then design the html so that the conventional POST would work.