I have a mailer class that wants to get the remote user. I access it my request.env['REMOTE_USER'] but get request not defined error. i thought i were able to use request anywhere?
undefined local variable or method request for my mailer
Why don't you try loading the remote user in your controller action, and either storing in the db, or redis when you're compiling your mailer
Request
The problem, as stated by Vimsha, is you're not able to access request params outside of front-facing code
According to Rails, how do you access the raw request data at the absolute lowest level?, you can access the data directly from the middleware if you're working with a direct request (I.E your mailer is not delayed etc)
Structure
Further to this, I would also question why you're accessing request-specific data directly from your mailer
The modular (DRY) nature of Rails means you need to be able to re-use as many of the assets as possible, meaning you may wish to use the mailer in a totally unrelated action
I'd personally store the request data in the db (or redis if you only want it temporarily), and access it on demand
Related
I'm building an app using Vue and Rails.
I have both the frontend and the backend separate (in separate folders)
The frontend is generated with vue-cli.
I have a situation where, I want to send some data to the backend via websockets, I want to set that data in something like a session object, and then access that data again on subsequent websocket interactions. Is that possible?
Would I need to set some kind of token in the browser, some kind of identifying token?
This seems like it would be a common problem but I can't find any information on it.
If you are utilizing session in rails websocket/connection.rb you won't be able to access it directly, but you can access it through the cookies object. The rails docs say this is labeled ['_session'] but for me on my browser it was ['_session_id'] then whatever data you set within session like a user id ['user_id']
cookies.encrypted['_session_id']['YOUR_DATA']
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.
When is the Rails request object available at the earliest time during the request lifecycle? Essentially, when is the request first available as a request object, and in which object? ActionDispatch?
Can you access request parameters from Tester::Application? If so, how? If not, what about using the environment? When is that information set?
The Rack webserver creates the request object and then ActionDispatch inherits from it. So essentially, you'd be able to access the Rack::Request or ActionDispatch::Request objects within the middleware of the app.
Rack::Request
https://github.com/rack/rack/blob/master/lib/rack/request.rb
ActionDispatch::Request
https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/http/request.rb
A middleware is probably the best way to access this data. I made a simple gem for setting up a raw HTTP request/response log in Rails using the classes mentioned in the accepted answer.
https://github.com/andrhamm/marcopolo
I want to grant users access to my API (hosted on heroku.com) from their sites.
But a strange problem occurs, when i want them to allow to post to the api:
Data sent from an correct form with the correct action-url (e.g. "http://myapp.com/projects/123/tasks/321/todos") - the params get serialized and send via jQuery - i encounter an "ActionController::MethodNotAllowed" with the additional info: "Only get and post requests are allowed", that re-routes to ApplicationController#index with :method => :options.
Rails doesnt extract the params for project_id (123) and task_id (321) from the url, neither are any further request_parameters, path_parameters or query_parameters available.
This behaviour occurs, when I POST from external sites, but doesn't occur, when posting from an html-page on my local machine. My first thought was about wrong encoding, but how to fix that problem.
Edit:
I am using authlogic (not devise :-D) and for the :create action the protect_from_forgery is already skipped.
Any suggestions appreciated
i guess that happens because rails tries to protect your form CSRF attacks.
you can comment out the protect_from_forgery line in your ApplicationController to test it.
but im not sure if thats the right way of dealing with this issue in the production environment.
Okay. I'll try and answer the right question this time (see other comment).
So I've thought about this, and I'm wondering, is this a case of the jQuery call attempting a PUT request? When you use the local form Rails will POST the data, but add the extra _method field to emulate a PUT.
Don't know if you are using jquery-rails, but this takes care of setting the _method parameter, and the PUT/POST verb translation for you in your AJAX calls.
The problem occured due to the cross domain policy - the request was made from another domain - and because I was using a recent browser that supports CORS, it was sending an OPTIONS-request first to get known from the server, which actions are allowed for this domain.
I want to access a given Requests ServerVariables, but I can't seem to find anything on Google on how to get access to the Server Vars of the request object. How do I do this or am I doomed to simply never know?
An example of why I'd want to do this (but not actually what I want to do):
User logs in, and you want to store the IP address of place where they logged in, or perhaps I want to record the user-agent or referer from the browser that they are viewing the site.
You should look at the request object that's available from the controller. There are a bunch of methods like
request.remote_ip
you can read more about the Request object on the Rails API site
The request accessor in a controller returns an ActionDispatch::Request object which can access all of the server variables you would expect.
Best documentation I've found for it is here: http://apidock.com/rails/v3.2.1/ActionDispatch/Request
Sometimes you have methods like request.remote_ip as mentioned in the other answer, other times you can access things via request.env, for example, to get the user agent, use request.env["HTTP_USER_AGENT"]