After
iex -S mix phx.server
I want to do some quick tests in the iex terminal, but some functions require the struct %Plug.Conn{} as an argument, for example I wanted to get the result of expression:
MyAppWeb.Router.Helpers.confirmation_url(%Plug.Conn{}, :edit, "12345")
But I've got error:
Phoenix endpoint not found in %{}
Is there a simple way of getting conn struct in the console?
Router helper functions accept either a conn or an endpoint module as the first argument. You can pass the endpoint module of your app when you want to generate a URL without a conn:
MyAppWeb.Router.Helpers.confirmation_url(MyAppWeb.Endpoint, :edit, "12345")
Edit: If you want to create a dummy conn that works with Router helpers, it seems like it's enough to put a %{phoenix_endpoint: MyAppWeb.Endpoint} value in conn.private as of Phoenix 1.3:
conn = %Plug.Conn{private: %{phoenix_endpoint: MyAppWeb.Endpoint}}
MyAppWeb.Router.Helpers.confirmation_url(conn, :edit, "12345")
The ConnCase test helpers use Phoenix.ConnTest.build_conn() to bootstrap a connection struct for the controller tests.
You can find the function here and either use it directly or follow its implementation and tweak it as you like.
Why spending time with testing on the console. Just write a test and use the 'ConnCase' which gives you the conn struct in your tests for free. During development you can also use the "test watch" package which will rerun your tests on every file change.
As soon as you switch to tdd as more time you will save with problems like this
Related
I'm trying to do a basic GraphQL query to a Shopify store with Sinatra. Could someone help me figure out what I'm doing wrong? I looked at their API to do this:
require 'shopify_api'
require 'sinatra'
class App < Sinatra::Base
get '/' do
shop = 'xxxx.myshopify.com'
token = 'shpat_xxxxxxxxxxxxxxxxxxxxxx'
session = ShopifyAPI::Session.new(domain: shop, token: token, api_version: "2021-04")
ShopifyAPI::Base.activate_session(session)
ShopifyAPI::GraphQL.initialize_clients
client = ShopifyAPI::GraphQL.client
SHOP_NAME_QUERY = client.parse <<-'GRAPHQL'
{
shop {
name
}
}
GRAPHQL
result = client.query(SHOP_NAME_QUERY)
result.data.shop.name
end
end
Which gives this error but I don't want to use Rake or Rails. Is it possible to do a GraphQL query to Shopify with Ruby?
ShopifyAPI::GraphQL::InvalidClient at /
Client for API version 2021-04 does not exist because no schema file exists at `shopify_graphql_schemas/2021-04.json`. To dump the schema file, use the `rake shopify_api:graphql:dump` task
As the error states, you need to first dump the schema (see this link: https://github.com/Shopify/shopify_api/blob/v9/docs/graphql.md#dump-the-schema).
Then you create a shopify_graphql_schemas directory in the same root as your ruby script, and put the generated JSON there.
Like stated in the comments, this requires a Rake task, so you need to be using Rails.
If your project doesn't use Rails, you need to do a quick workaround.
You create a temporary barebones Rails project, then generate the dump using that project (you can delete the project when you're done with this).
It's a bit hacky, but it's the only thing I can see that would work.
New link to schema dump
https://github.com/Shopify/shopify_api/blob/v9/docs/graphql.md#dump-the-schema
You need to use something like this
rake shopify_api:graphql:dump SHOP_DOMAIN="SHOP_NAME.myshopify.com" ACCESS_TOKEN="SHOP_TOKEN" API_VERSION=2022-04
Old one doesn't work anymore
I have a modular Sinatra app that runs fine under rackup, that is with a config.ru that has three 'use' statements and one run statement. I am trying to get my head around how to port the application to AWS lambda where API_gateway will provide web server services and just call my app.
I am using the recommended lambda.rb script from https://github.com/aws-samples/serverless-sinatra-sample/blob/master/lambda.rb as my entrypoint. What I don't get is how, in the AWS Lambda micro-clime, do I assemble the modules/layers of my application without rackup and config.ru?
I assume that my noob brain is just missing something really basic in spite of the fact that I have read every blog post, bit of Sinatra and Rack documentation I know of, and the great "Sinatra Up and Running" book. What am I missing?
Upon re-reading the book, "Sinatra: Up and Running" again, it seems that there is a fairly elegant solution. If I set up my lambda.handler entrypoint to point to a simple Sinatra router, then it will be the router that composes the individual controllers into a 'system' which will handle all of my end points. the example from the book:
Example 4-32. Using Sinatra as router
require 'sinatra/base'
class Foo < Sinatra::Base
get('/foo') { 'foo' }
end
class Bar < Sinatra::Base
get('/bar') { 'bar' }
end
class Routes < Sinatra::Base
get('/foo') { Foo.call(env) }
get('/bar') { Bar.call(env) }
end
run Routes
Of course, in my case, I won't need the 'run Routes' line. I will just have my lambda.handler call Routes, as in Routes.call. This seems very doable!
Does anyone know of a way of changing the :host of the Phoenix application endpoint dynamically on every request?
Specifically to support multiple domains on a single phoenix app, i want to change the host in the endpoint based on the host in the connection object.
Am trying something on the lines of
conn = Map.get_and_update(conn.private.phoenix_endpoint[:url], :host, fn (_) -> "ll.com" end)
or
Keyword.put(conn.private.phoenix_endpoint.config(:url), :host, conn.host)
But am not quite correct.
Wouldn't it just be a value you assign the :to keyword in the redirect?
def index(conn, params) do
redirect conn, to: params[:location] # or whatever
end
The master_proxy package offers some useful tools to support multiple sites.
How do I mount/run multiple rack apps without using map or Rack::UrlMap? Using these will dispatch the apps fine, but will also prefix the route used for dispatch to the beginning of the matcher, so:
class API < Sinatra::Base
get "/api" do
# blah
end
end
map( "/api" ) { run API }
The route above is accessed at "/api/api" which is not what I want, just "/api" is what I want. I don't want to dig into the request object with a filter and remove prefixes if there's a better way.
I've tried:
use API.app # the app is wrapped in a `def self.app` for convenience.
run Web.app
but use causes problems if the app itself has used use within it too. Doing this:
run API.app
run Web.app
will only serve routes from the last app given to run.
I'm about to try Rack::Cascade but I've never used that before and don't know if it's a good answer to this problem.
The answer is indeed Rack::Cascade:
run Rack::Cascade.new( [API, Web] )
I am working on a website hosted on microsoft's office live service. It has a contact form enabling visitors to get in touch with the owner. I want to write a Ruby script that sits on a seperate sever and which the form will POST to. It will parse the form data and email the details to a preset address. The script should then redirect the browser to a confirmation page.
I have an ubuntu hardy machine running nginx and postfix. Ruby is installed and we shall see about using Thin and it's Rack functionality to handle the script. Now it's come to writing the script and i've drawn a blank.
It's been a long time and if i remember rightly the process is something like;
read HTTP header
parse parameters
send email
send redirect header
Broadly speaking, the question has been answered. Figuring out how to use the answer was more complicated than expected and I thought worth sharing.
First Steps:
I learnt rather abruptly that nginx doesn't directly support cgi scripts. You have to use some other process to run the script and get nginx to proxy requests over. If I was doing this in php (which in hind sight i think would have been a more natural choice) i could use something like php-fcgi and expect life would be pretty straight forward.
Ruby and fcgi felt pretty daunting. But if we are abandoning the ideal of loading these things at runtime then Rack is probably the most straight forward solution and Thin includes all we need. Learning how to make basic little apps with them has been profoundly beneficial to a relative Rails newcomer like me. The foundations of a Rails app can seem hidden for a long time and Rack has helped me lift the curtain that little bit further.
Nonetheless, following Yehuda's advice and looking up sinatra has been another surprise. I now have a basic sinatra app running in a Thin instance. It communicates with nginx over a unix socket in what i gather is the standard way. Sinatra enables a really elegant way to handle different requests and routes into the app. All you need is a get '/' {} to start handling requests to the virtual host. To add more (in a clean fashion) we just include a routes/script.rb into the main file.
# cgi-bin.rb
# main file loaded as a sinatra app
require 'sinatra'
# load cgi routes
require 'routes/default'
require 'routes/contact'
# 404 behaviour
not_found do
"Sorry, this CGI host does not recognize that request."
end
These route files will call on functionality stored in a separate library of classes:
# routes/contact.rb
# contact controller
require 'lib/contact/contactTarget'
require 'lib/contact/contactPost'
post '/contact/:target/?' do |target|
# the target for the message is taken from the URL
msg = ContactPost.new(request, target)
redirect msg.action, 302
end
The sheer horror of figuring out such a simple thing will stay with me for a while. I was expecting to calmly let nginx know that .rb files were to be executed and to just get on with it. Now that this little sinatra app is up and running, I'll be able to dive straight in if I want to add extra functionality in the future.
Implementation:
The ContactPost class handles the messaging aspect. All it needs to know are the parameters in the request and the target for the email. ContactPost::action kicks everything off and returns an address for the controller to redirect to.
There is a separate ContactTarget class that does some authentication to make sure the specified target accepts messages from the URL given in request.referrer. This is handled in ContactTarget::accept? as we can guess from the ContactPost::action method;
# lib/contact/contactPost.rb
class ContactPost
# ...
def action
return failed unless #target.accept? #request.referer
if send?
successful
else
failed
end
end
# ...
end
ContactPost::successful and ContactPost::failed each return a redirect address by combining paths supplied with the HTML form with the request.referer URI. All the behaviour is thus specified in the HTML form. Future websites that use this script just need to be listed in the user's own ~/cgi/contact.conf and they'll be away. This is because ContactTarget looks in /home/:target/cgi/contact.conf for the details. Maybe oneday this will be inappropriate, but for now it's just fine for my purposes.
The send method is simple enough, it creates an instance of a simple Email class and ships it out. The Email class is pretty much based on the standard usage example given in the Ruby net/smtp documentation;
# lib/email/email.rb
require 'net/smtp'
class Email
def initialize(from_alias, to, reply, subject, body)
#from_alias = from_alias
#from = "cgi_user#host.domain.com"
#to = to
#reply = reply
#subject = subject
#body = body
end
def send
Net::SMTP.start('localhost', 25) do |smtp|
smtp.send_message to_s, #from, #to
end
end
def to_s
<<END_OF_MESSAGE
From: #{#from_alias}
To: #{#to}
Reply-To: #{#from_alias}
Subject: #{#subject}
Date: #{DateTime::now().to_s}
#{#body}
END_OF_MESSAGE
end
end
All I need to do is rack up the application, let nginx know which socket to talk to and we're away.
Thank you everyone for your helpful pointers in the right direction! Long live sinatra!
It's all in the Net module, here's an example:
#net = Net::HTTP.new 'http://www.foo.com', 80
#params = {:name => 'doris', :email => 'doris#foo.com'}
# Create HTTP request
req = Net::HTTP::Post.new( 'script.cgi', {} )
req.set_form_data #params
# Send request
response = #net.start do |http|
http.read_timeout = 5600
http.request req
end
Probably the best way to do this would be to use an existing Ruby library like Sinatra:
require "rubygems"
require "sinatra"
get "/myurl" do
# params hash available here
# send email
end
You'll probably want to use MailFactory to send the actual email, but you definitely don't need to be mucking about with headers or parsing parameters.
CGI class of Ruby can be used for writing CGI scripts. Please check: http://www.ruby-doc.org/stdlib/libdoc/cgi/rdoc/index.html
By the way, there is no need to read the HTTP header. Parsing parametres will be easy using CGI class. Then, send the e-mail and redirect.