Well, so far in each article I see people say server respond accordingly to the request type. If it is xml request then response is in xml and if it is ajax or html then response is in ajax or html. Browser send the request and server respond accordingly. My question is in rails app in which part this decision is taken? That is by server which part of the rails app we indicate?
This decision is taken inside the controller of the rails MVC framework and can be modified by the user. The user may wish not to respond to a particular type of request.
The distinction is made by suffix in URI, eg. ..../users/123.json. And You do it by yourself in controller.
Related
I have an app where I try to adhere to REST.
The app receives requests for external links that don't belong to the app, so the sole purpose of the action is to redirect the request to the external URL.
My suggestion is to have the following controller/action: redirects_controller#create.
Is my thinking correct or should it be the show action instead?
REST (apart from Rails) is about using the correct HTTP method for the correct action. The Rails part is just using the conventional controller action for a given HTTP method.
So, if you're doing a 301 or 302 redirect to another page, which browsers handle by issuing a GET request to the URL in the redirect response's Location header, do it in a show action. This will allow the user's browser to cache the other page when appropriate, and to not notify the user before redirecting.
(There is a way to redirect POSTs, but you didn't mention it so I expect you're talking about regular 301/302 redirects.)
Coming from a Java background, the REST actions must be related to CRUD operations. Requests that do not change the resource like in your case where the intent is to redirect to another page must be tied to a GET verb or show in your example.
If you were to create a new resource you would use POST.
A more detailed explanation can be found in Richardson's rest maturity model level 2
I'm recently facing the problem with last request url after login. Normally, everything works properly. But if I proceed following procedure I have troubles:
Open an App in one tab and log in
In this tab I go somewhere where AJAX request to the server are proceeded regularly
Open a new tab with the app (I'm still logged-in)
In this tab I log out
In the mean time the AJAX request from the 1st tab is proceeded automatically
with HTTP 401 (cause I've logged-out)
When I try to log in again in the 2nd tab than I receive the JSON of the AJAX request from the 1st tab because it was the last request.
I would suspect that Spring Security would neglect AJAX request for "last request url". Is it possible to set this somewhere? Or is there any good workaround to this?
Thanks,
Mateo
I don't think there is a general way to distinguish ajax requests from "regular" requests initiated by the user navigating a browser. If you can distinguish them in your application (e.g. by mapping ajax requests to specific urls that can be matched against some patterns), you could easily implement what you are looking for. (EDIT: An easier way to identify ajax requests is suggested by Sérgio in his below comment.)
The component that is responsible to perform redirection after a successful login is SavedRequestAwareAuthenticationSuccessHandler, therefore one possibile way to customize the framework's default behavior is to provide your own AuthenticationSuccessHandler, and inject it into the UsernamePasswordAuthenticationFilter. It should be possible to autowire the RequestCache in your class, and decide if you want to replay the last cached request or just ignore it in case it's known to be an ajax request.
i have my own AuthenticationSuccessHandler and overriding method onAuthenticationSuccess, where i need to redirect to some page with parameters from request before authenticate (i hope you understand what i mean, sorry for my english)
getRedirectStrategy().sendRedirect(request, response, targetUrl);
How can i do this with POST method (by default it is GET method)
You may do it without sendRedirect method using HTTP1.1 307 Temporary Redirect status code.
But AFAIK this is not a common practice and not all web browsers may support this.
Maybe server-side forward will suit your case.
Update:
If you want to send POST-redirect using spring-security API you may implement your own RedirectStrategy.
DefaultRedirectStrategy uses response.sendRedirect that will result in 302 response code sending by servlet container (I'm not sure about every container, at least tomcat sends 302).
Update 2:
You may send 307 back setting response status and "Location" header yourself:
resp.setStatus(SC_TEMPORARY_REDIRECT);
resp.setHeader("Location", absoluteRedirectUrl);
User-agent receiving this response must do next request using the same method that was used in previous request. So if first request was POST redirected request also will be POST.
I'm a novice in ruby on rails trying to understand the in-depth flow of a typical request/response life cycle in ruby on rails web application.
I have googled for the info and have not found an answer which is complete or detailed to the level of DNS servers to dispatchers.
The closest I got to a good explanation is at:
http://brainspl.at/request_response.pdf.
Can someone point me to a better or more detailed explanation?
-Raviteja
So you are asking for rails request/response cycle and you already referred to a presentation which really describes it very well. So im assuming that you want to know it from a very high level and you need this concept totally for development. Then here it is. Im just trying to name the parts sequentially.
Route: Here you will draw the paths which will be used by the world to access your application. With a complete RESTful architecture, you need to define the hierarchy of your resources and define how a resource can be accessed to perform some action. If any request to your application doesnt match with any path in the routes file, it will not be processed. If any match occurs, it will find the corresponding controller and action and will call it. At the time of calling, it will store all the request related data in params hash.
Before Filters: Now your application already know which controller#method is gonna process the request. And it will check if there is anything configured to execute before calling that method. This is done by using before_filter. If found anything then those functions will be called first.
Method Execution: After executing all the before_filter methods in a particular sequence, it will call the actual method. All the data is available in params hash in this method. It processes input data, invokes Model calls for database access, and prepare data for view.
View: Proper view file will be chosen based on the controller#action, format. Or you might select any particular view to render by render :partial call. And the response will be prepared using the variables prepared in controller. This response will go to the client.
After Filters: After processing the view, it will look after_filter methods and will those if found.
Well this was a quick overview i would say, without really any details. Im saying again, the pdf you referred really contains more details.
Let me know if you want to know anything more specifically.
A user opens his browser, types in a URL, and presses Enter. When a user presses Enter, the browser makes a request for that URL.
The request hits the Rails router (config/routes.rb).
The router maps the URL to the correct controller and action to handle the request.
The action receives the request, and asks the model to fetch data from the database.
The model returns a list of data to the controller action.
The controller action passes the data on to the view.
The view renders the page as HTML.
The controller sends the HTML back to the browser. The page loads and the user sees it.
https://www.codecademy.com/articles/request-response-cycle-dynamic
and https://www.codecademy.com/articles/request-response-cycle-forms
Everything starts when ‘url’ requested by a user. The browser needs to know sever’s IP address to connect, So it lookup DNS(Domain name system) which translate your domain into the public IP address of the particular server. Then the Browser will do threeway handshake to connect server like puma in port 80. And decide upon public and private key it happen only because if url use HTTPS. HTTPS is a secure wrapper around HTTP and TCP. Then Server triggers the rails application through middleware like rack and provides request verb, header, body to the application. Then rails application use Journey (Default route library of rails) to find the consent controller and action which matches the request and call with the request and params.
Then rails lifecycle callbacks like before, after, around will be triggered during the process. The action takes care of requesting data from the model and rendering the consent view for the request. Finally sent back the status, header, and body as the response.
If you want to learn in-depth about lifecycle, check this article The Lifecycle of a Request
It is also important to note that Rails apps use an MVC architectural pattern, which is Model, View, and Controller at a high-level the life-cycle of a request in rails app is simply the interaction of the Model, View, and Controller. This article gives you an overview.
I have to make a call to a different url in one of my controllers on my site. The problem is that with all the parameters the other site requires I'm overflowing the url. Is there anyway to call another url from the controller and send all of the parameters using a POST?
I'm not expecting a response from the other site. Also, I think there's a way to do this using the Net::HTTP library thought I'm not sure how.
Thanks
You can't do a redirect and send POST data at the same time in the HTTP spec. Redirects are implemented by sending a simple Location: otherlocation.html header. POST data doesn't fit anywhere into that system.
Do you want the user to go to this page, or do you want to just send the data to the application yourself? If you want to send the data and not send the user there, use Ruby's Net::HTTP module. If you want to send the user, you may be forced to output a view with a form, and submit it automatically with Javascript. (Don't forget to degrade gracefully by offering a submit button in noscript tags.)
This is from the ruby docs:
require 'net/http'
require 'uri'
result = Net::HTTP.post_form(URI.parse('http://www.example.com/search.cgi'),
{'q'=>'ruby', 'max'=>'50'})
As you can see, you pass the params in as a convenient hash, unlike other languages that make you mess with http formatting.
You can also use the flash to transfer the information.
http://guides.rubyonrails.org/action_controller_overview.html#the-flash