Local jets server causes 404 in cloud9 because of "/dev" path prefix

bug

#1

I’m trying to develop a jets app in the cloud9 IDE.
When running locally the links point to domain.com**/dev**/fu instead of domain.com/fu and generate a 404 error.
E.g.:
https://[…].vfs.cloud9.us-east-1.amazonaws.com/dev/locations/new
instead of the working:
https://[…].vfs.cloud9.us-east-1.amazonaws.com/locations/new

How do I either remove the “/dev” or change the path to become valid?


#2

Interesting. Thought this was fixed by this PR: https://github.com/tongueroo/jets/pull/202

Just tested it and it worked. Looks like this was released in v1.8.6. https://github.com/tongueroo/jets/issues/201 Hoping that all you need to do is upgrade your version of Jets.


#3

Thanks for the quick reply, Tung!

This is a new project and I’m running Jets 1.8.11.
Can I provide any additional information?

My URL is:
https://[id].vfs.cloud9.us-east-1.amazonaws.com/

Here are the commands I ran after setting up Cloud9 on us-east-1:

npm install -g yarn  
npm install -g npm 
apt install libmysqlclient-dev mysql-server
[creating mysql user]

gem install jets
jets new onboarding
cd onboarding
nano .env.development
jets db:environment:set RAILS_ENV=development
[some scaffolding]
jets db:create
jets db:migrate
jets server --port=8080

My current workaround is setting namespace :dev for my resources in routes.rb.


#4

Odd :thinking: Thought maybe it was related to the region you were running in: us-east-1. But created a cloud9 machine in us-east-1 and tested and it worked fine for me. So it’s not region related.

Wondering what value your cloud9 environment has for the HTTP_HOST env variable. The env is from the rack request. HTTP_HOST should be a pattern that matches the /cloud9\..*\.amazonaws\.com/ regexp.

Maybe add puts ENV["HTTP_HOST"] to one of your conrtrollers. Example:

class PostsController < ApplicationController
  def index
    puts ENV["HTTP_HOST"]
    puts ENV['HTTP_X_AMZN_TRACE_ID']
  end
end

#5

They are both empty.
I will try generating a new cloud9 environment, although I can’t think of anything I did that would have caused this.


#6

Same issue with a fresh environment and the variables are empty as well.
The only non default option I choose was Ubuntu instead of Amazon Linux.
Trying a fresh env with Amazon to see if that fixes it.


#7

Nope, same issue in a brand new Amazon Linux environment.
I also don’t see these variables with printenv.
Do they show up in your instance that way?


#8

Can I set these variables manually as a workaround?
I tried:
HTTP_HOST=‘622ae2c859c38ac4bd96524423a6a3ff.vfs.cloud9.us-east-1.amazonaws.com
HTTP_X_AMZN_TRACE_ID=‘Root=1-67891233-abcdef012345678912345678’
(The second value is from Google)
But it didn’t work.


#9

So sorry. Didn’t test it before asking the question. :man_facepalming:t2: The env that we want to see is by the time it gets to the on_aws? call. Let’s try again:

Modification to the code

Run this to show where the jets source is on your machine, you should see something like this:

$ bundle show jets
/home/ec2-user/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/jets-1.8.13

From there go to:

lib/jets/controller/middleware/local.rb

Modify the on_aws?(env) with some puts debugging:

    def on_aws?(env)
      puts "on_aws? HTTP_HOST #{env['HTTP_HOST'].inspect}"
      puts "on_aws? HTTP_X_AMZN_TRACE_ID #{env['HTTP_X_AMZN_TRACE_ID'].inspect}"
      
      return false if ENV['TEST'] # usually with test we're passing in full API Gateway fixtures with the HTTP_X_AMZN_TRACE_ID
      on_cloud9 = !!(env['HTTP_HOST'] =~ /cloud9\..*\.amazonaws\.com/)
      !!env['HTTP_X_AMZN_TRACE_ID'] && !on_cloud9
    end

Start a server and load the endpoint in a browser

jets server --host 0.0.0.0 --port 8080

You should use the url it spits out and load it in the browser now.

Outputs

It should output something like this.

on_aws? HTTP_HOST "f5cb4c999c38432d844bf88961fe3123.vfs.cloud9.eu-central-1.amazonaws.com"
on_aws? HTTP_X_AMZN_TRACE_ID "Root=1-5cdf2db2-060617c8606fb41031f12b20"

#10

Hi, I’m facing the very same issue with version 1.8.14.

Just did what @tung instructed and this is the terminal output, when starting the server:

on_aws? HTTP_HOST “68a186fa087a4b57822ecb22b176e0c6.vfs.cloud9.us-east-2.amazonaws.com
on_aws? HTTP_X_AMZN_TRACE_ID “Root=1-5ce5af65-b6719cd5d6a5cdc4cda0d2fc”

It looks like the variable is set correctly. Anything else we can do to get rid of the “/dev” path?

FWIW: I’m not sure if this relates to the issue, but I’m using RVM to handle gemsets in the environment.

My best,
Marcos.


#11

Figured it out: https://github.com/tongueroo/jets/pull/256 Didn’t realize it was in the generated html source, once realized that, was a quick fix.

Will go out in the next release.


#12

Thanks @tung , it partially solved the issue.

Problem persists when hitting the redirect_to method inside #create and #update actions:

# /lib/jets/controller/redirection.rb

      if !uri.host && actual_host
        url = "/#{url}" unless url.starts_with?('/')
        url = add_stage_name(url)
        redirect_url = actual_host + url
      else
        redirect_url = url
      end

It looks like there is another add_stage_name method inside the rendering.rb file:

# /lib/jets/controller/rendering.rb

    def add_stage_name(url)
      return url unless actual_host
      if actual_host.include?("amazonaws.com") && url.starts_with?('/')
        stage_name = Jets::Resource::ApiGateway::Deployment.stage_name
        url = "/#{stage_name}#{url}"
      end
      url
    end

I’m kinda new to all this thing and I don’t want to break anything, so I’m just replicating the solution in this file for now.

Would love to know if it’s possible to remove this duplication and make both calls to the method inside the common_methods.rb file.


#13

Fixed in https://github.com/tongueroo/jets/pull/259