Make api calls to custom heroku domain - ruby-on-rails

I'm building an open API with rails and hosting my project on Heroku. However I want my API calls to be from mydomain.co instead of heroku's domain.
I added my domain from Heroku dashboard, and I also forwarded my domain to heroku's url.
However when I make the 'POST' call like below:
curl -H "Content-Type: application/json" -d '{"myjsontitle":{"field1":"eerbil.eren#derivalabs.com","field2":"12345678"}}' -X POST http://deriva.co/applicants.json
Terminal returns the following:
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
And when I look at the heroku logs, it says
at=info method=GET path="/applicants.json" host=stark-bayou-1773.herokuapp.com
How should I fix that problem?
Thanks!

There is an error with your DNS configuration.
➜ ~ curl -I deriva.co
HTTP/1.1 302 Found
Cache-Control: max-age=900
Content-Type: text/html; charset=utf-8
Location: https://stark-bayou-1773.herokuapp.com
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 02 Feb 2015 19:59:45 GMT
Content-Length: 155
Age: 67
Connection: keep-alive
deriva.co redirects to Heroku, whereas it should resolve to it. You probably used a sort of provider redirect, which is not the correct DNS configuration. You need to "point" the DNS to Heroku.
Please note that you can't map deriva.co to Heroku directly unless your providers supports a CNAME-like configuration for the root domain. And GoDaddy does not.
You either need to change DNS provider or point www.deriva.co using a CNAME and redirect deriva.co to www.deriva.co.

Related

Digital ocean managed deployed rails APP not responding to http (returns 404)

I followed this 3 parts tutorial and successfully deployed a Rails app in a Managed Digital Ocean App.
Locally, I can use httpie to GET resources and POST to create new users such as:
http :8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
But, once deployed on digital ocean with at this url with valid TCP health check, I try to create an user (with http/postman):
http mtserver-igkkx.ondigitalocean.app:8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
and end up with:
HTTP/1.1 301 Moved Permanently
CF-RAY: 6d851c0f7951408d-CDG
Cache-Control: max-age=3600
Connection: keep-alive
Date: Fri, 04 Feb 2022 16:00:02 GMT
Expires: Fri, 04 Feb 2022 17:00:02 GMT
Location: https://mtserver-igkkx.ondigitalocean.app/signup
Server: cloudflare
Transfer-Encoding: chunked
Vary: Accept-Encoding
Assuming I need to prefix the URL with https, i try again with:
http https://mtserver-igkkx.ondigitalocean.app:8080/signup name=test email=test#email.com password=foobar password_confirmation=foobar
And end up with:
http: error: SSLError: HTTPSConnectionPool(host='mtserver-igkkx.ondigitalocean.app', port=8080): Max retries exceeded with url: /signup (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:997)'))) while doing a POST request to URL: https://mtserver-igkkx.ondigitalocean.app:8080/signup
If I try a POST with postman:
POST > mtserver-igkkx.ondigitalocean.app:8080/signup?name=test&email=test#mail.com&password=foobar&password_confirmation=foobar
it returns:
{
"status": 404,
"error": "Not Found"
}
While visiting the server URL on '/' it returns a 404 but I assume it's normal as it's only supposed to work in API mode and no route currently handles /.
I'm Looking forward to understand how to handle digital ocean in production to be able to create users on this API through http requests.
For the record, ssl was the problem.
You need to go through the process of adding a SSL certificate through digital ocean so https (and further your web app) works when you query the prefixed url.
This unanswered SO post helped me a lot to figure out the good process.

Artifactory Docker 404 after upgrade to 7.4.1

After an Artifactory upgrade to 7.4.1 from 6.10.4, I've made the necessary port changes and the UI works fine, but I'm seeing the following in the artifactory-service log when attempting to use docker login via the subdomain method:
Request /v2/ should be a repo request and does not match any repo key
The docker login command prompts for authentication but then returns:
Error response from daemon: login attempt to http://<local-docker-repo>.<artifactory-url>.com/v2/ failed with status: 404 Not Found
Artifactory is running in a Kubernetes cluster behind an nginx ingress controller, which has an ingress set up specifically to serve https://<local-docker-repo>.<artifactory-url>.com via the same backend as the Artifactory UI. It seems like some URL rewrite functionality is not working, I'm just not sure how I've misconfigured it as I had no problems in the previous version.
Curl results as follows:
curl -i -L -k http://docker-local.<artifactory-url>.com/v2/
HTTP/1.1 308 Permanent Redirect
Server: nginx/1.15.9
Date: Mon, 21 Sep 2020 00:25:32 GMT
Content-Type: text/html
Content-Length: 171
Connection: keep-alive
Location: https://docker-local.<artifactory-url>.com/v2/
X-JFrog-Override-Base-Url: ://docker-local.\<artifactory-url>.com:80
X-Forwarded-Port: 80
Host: docker-local.artifactory.<artifactory-url>.com
X-Forwarded-For: 10.60.1.1
HTTP/2 401
server: nginx/1.15.9
date: Mon, 21 Sep 2020 00:25:32 GMT
content-type: application/json;charset=ISO-8859-1
content-length: 91
www-authenticate: Basic realm="Artifactory Realm"
x-artifactory-id: ea0c76c54c1ef5de:45761df0:174ad9a6887:-8000
x-artifactory-node-id: artifactory-0
x-jfrog-override-base-url: ://docker-local.<artifactory-url>.com:443
x-forwarded-port: 443
host: docker-local.<artifactory-url>.com
x-forwarded-for: 10.60.x.x
strict-transport-security: max-age=15724800; includeSubDomains
{
"errors" : [ {
"status" : 401,
"message" : "Authentication is required"
} ]
Any help would be greatly appreciated!
Edit: As a workaround I've enabled Repository Path as the Docker access method, which works fine -- still not sure where subdomain is going wrong.
The issue was that the $repo variable in the nginx rewrite rules provided by Artifactory was not getting populated for some reason. Since we only have a single registry being used in the subdomain method, I updated the rewrite rule to provide the repo name which resolved the issue.
To illustrate:
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/$repo/$1/$2;
was changed to:
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/docker-local/$1/$2;

Insufficient scope when attempting to get Docker Hub catalog

I'm attempting to get a catalog listing for Docker hub, but so far I'm just getting an error in response. My understanding is I'd need to pass a bearer token with the catalog request, so I start by getting that token with the related scope:
curl -u "username:password "https://auth.docker.io/token?service=registry.docker.io&scope=registry:catalog:*"
(this is using username/password from my Docker Hub account)
I then pass the returned token to the registry:
curl -vL -H "Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6I(...)" https://registry-1.docker.io/v2/_catalog
In response to that request, I'm getting:
* Trying 54.86.130.73...
* Connected to registry-1.docker.io (54.86.130.73) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.docker.io
* Server certificate: RapidSSL SHA256 CA - G3
* Server certificate: GeoTrust Global CA
> GET /v2/_catalog HTTP/1.1
> Host: registry-1.docker.io
> User-Agent: curl/7.43.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6I(...)
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="registry:catalog:*",error="insufficient_scope"
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="registry:catalog:*",error="insufficient_scope"
< Date: Fri, 06 May 2016 23:00:08 GMT
Date: Fri, 06 May 2016 23:00:08 GMT
< Content-Length: 134
Content-Length: 134
< Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
<
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Name":"catalog","Action":"*"}]}]}
...which seems to be asking me to go back and get authorized with the URL I entered above.
Should this be possible? If so, what am I missing?
I got the same problem, raised this with docker support and got the following answer,
"The catalog endpoint does not work against Docker Hub because that endpoint actually lists all the repositories on a Registry, and we disabled it as it would list all repositories on Docker Hub."
If you want repository information for a username or organization, an alternative is to use V1 api. The problem with this is you need to make multiple calls based on the number of repos available.
The following command will give the repos available for a given username :
curl -k -H "Authorization: Basic <encripted username:password>" -H "Accept: application/json" -X GET "https://index.docker.io/v1/search?q=<username>&n=100"
Here q is the query and n is the number of items to be returned in each page.
Another call can be made based on what data you need by passing repo as a parameter.

Heroku / Cloudfront / Fonts / Firefox

There are quite a few SO questions (1, 2, 3, etc.) that go over the same problem I am having (fonts are not displaying on FireFox due to CORS issue). I have tried all of the proposed solutions in the above questions as well as various blog posts that come up when Googling the issue.
In my specific case I am using Cloudfront on Heroku but I am not using S3 (my assets are pulled to the CDN on first request). I am also using site-wide SSL (and I'm not sure if this is what is causing my issues as all the other examples seem to be for http:// sites). Currently I am trying to use the font_assets gem but when I curl one of my font files (or even a jpg file) I am getting a 301 Moved Permanently instead of a 200.
curl -i https://d2loy3ox2q4ikr.cloudfront.net/assets/fontawesome-webfont-9a3b8f90662fe9149f07a059f1a4c782.woff
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Date: Wed, 09 Apr 2014 12:27:33 GMT
Location: https://www.transdraft.com/assets/fontawesome-webfont-9a3b8f90662fe9149f07a059f1a4c782.woff
Status: 301 Moved Permanently
X-Cache: Miss from cloudfront
Via: 1.1 1316c66c042cd4b103a533bbf48877a5.cloudfront.net (CloudFront)
X-Amz-Cf-Id: NciaYbAYVS7OpY6ORzjeZMurd_cyBo-B1WfN1QZbSexbM2DoD0vWqg==
curl -i https://d2loy3ox2q4ikr.cloudfront.net/assets/transdraft-hp-2-0fa26dc608ff6a3ea83a093dce8e6338.jpg
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Date: Wed, 09 Apr 2014 12:28:47 GMT
Location: https://www.transdraft.com/assets/transdraft-hp-2-0fa26dc608ff6a3ea83a093dce8e6338.jpg
Status: 301 Moved Permanently
X-Cache: Miss from cloudfront
Via: 1.1 c8b893f88c46deef2c0f22aefa2d3ecc.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 897u3X7te5f167cZlJiBME1UlBp5NYtGrKm18D4FWOHlTEFMITYTLw==
Any idea what I might be doing wrong?
I fixed this same issue by modifying my application.css.scss to use SCSS imports instead of requires.
From:
//= require font-awesome
To:
#import 'font-awesome';
This may not work for you if you're not using SCSS.

RSS parsing error on Heroku

I'm doing some simple RSS parsing and rendering - works perfectly fine on localhost and production at Heroku, but for some reason this particular RSS feed works only on localhost, but not when deployed at Heroku.
Here is the RSS feed:
http://careers.joelonsoftware.com/jobs/feed?tags=network
Here is the error I get on Heroku:
A ActionView::Template::Error occurred in jobs#index:
503 Service Unavailable
/usr/local/lib/ruby/1.9.1/open-uri.rb:346:in `open_http'
Here is my code:
#rss = RSS::Parser.parse(the_rss_feed, false)
render :partial => "layouts/rss_syndicated_jobs", :locals => {:rss => #rss}
I'm requiring:
require 'rss/2.0'
require 'open-uri'
This seems to be a perfectly valid RSS feed - and again, works fine on localhost - but not when deployed at Heroku....any thoughts?
That domain doesn't like heroku's servers making HTTP GET requests.
From Heroku
➜ deefour ✗ heroku run "curl -s -D - careers.joelonsoftware.com/jobs/feed -o /dev/null"
Running `curl -s -D - careers.joelonsoftware.com/jobs/feed -o /dev/null` attached to terminal... up, run.9211
HTTP/1.0 503 Service Unavailable
Cache-Control: no-cache
Connection: close
Content-Type: text/html
From Local Machine
➜ deefour ✗ curl -s -D - careers.joelonsoftware.com/jobs/feed -o /dev/null
HTTP/1.1 200 OK
Cache-Control: private, max-age=1800
Content-Type: application/rss+xml; charset=utf-8
Expires: Tue, 27 Nov 2012 02:46:38 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: x-requested-with
Access-Control-Max-Age: 60
Date: Tue, 27 Nov 2012 02:16:38 GMT
Content-Length: 10982
If you print the response body through Heroku it provides the following info
This IP is only allowed to access our API.
To protect our users, we can't process requests from this IP address.
If you believe you have reached this page in error, contact us.

Resources