C9 workspace shopify ROR app redirect problem of App proxy request

ruby

#1

Hi,
From 8th June, 2017 workspace for my Ruby on rails app for shopify does not response for proxy call. I am developing a shopify app on “Ruby on rails” on of my workspace. On the app development stage I have to test proxy call from my website to Ruby on rails app url that is developing on c9 . Before the 8th June, 2017 everything was working fine. But after that date the proxy call redirect to this page “https://c9.io/preview/app/…” where the page content show text like- Welcome to the Cloud9 IDE Application Preview****This is the preview of an application being developed with Cloud9 IDE and there is a button “Open the app”.When click the button “Open the app” it redirect to app home url means the workspace preview url but it should only response data from the back end. My development flow is stuck in for this.

This issue is arise after you have made some change on 8 june, 2017.
Please try to fix the bug.


#2

I was also having similar problems for a completely different application. Would be great if we could disable this redirection.


#3

###Update:

I was able to get everything working via ngrok. This can be done very easily from the terminal (and can even be added to your startup script) using the following commands:

wget https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip
unzip ngrok-stable-linux-amd64.zip
./ngrok http 8080

Make sure to change the port number in the last line (8080) if that’s not the one you’re using.

###Hope this helps!


#4

Using a tunel could be a solution for this issue.But that wouldn’t be a wise decision. In future may face more problem…


#5

What type of issues do you think there might be?


#6

Having to go in and change the app settings every time I want to work on it is a bit of a hassle since the address changes every time I fire up ngrok. Without the tunnel the app was working.


#7

We have found a workaround for shopify requests, by not showing the proxy for requests with x-request-id, this fix will be released next week.
@rocketinventor what issue did you see? maybe we could fix it by adding more headers to our whitelist.


#8

I was trying to test out a new Twilio application. In addition to whitelisting x-request-id (Ajax) requests, I would suggest adding a user-agent whitelist. There are all types of times when people might try to make requests with non-browser devices with other headers and it doesn’t make sense to have to add each individual device to a bypass list (i.e. IoT devices). In addition, I would suggest leaving a workplace option allowing the user to disable the redirection and/or adjusting the redirection so that it only redirects once. Having to click through that screen every time I want to test out a new browser/device and every time I restart my server gets to be really annoying.


#9

we already check for user-agent: we skip the screen if one of the following conditions is true

 req.method != "GET"
 || !/Mozilla|AppleWebKit/.test(req.headers["user-agent"])
 || !/text\/html/.test(req.headers["accept"])
 || "origin" in req.headers
 || "postman-token" in req.headers
 || "x-request-id" in req.headers
 || "x-request-id-sig" in req.headers 

if you know of any other check that would help you, please let us know