This post shows how to add a certificate to an application, my question, is there a way to add multiple certificates both non-wildcard and wildcard certificate to a single application.
For example, I have an app called websites where it is home to multiple websites, is it possible to set several certificates to this application using Flynn?
You can add as many domains/certificates as you want to an app.
Use the flynn route add http $DOMAIN -c $CERTIFICATE_PEM_FILE -k $KEY_PEM_FILE command to add additional routes. You can distinguish between routes in requests to the app by checking the HTTP Host header.
Related
I am currently trying to host a website as an experiment on Heroku, I deployed the back end which you can consider yyyy.herokuapp.com and the front end with you can consider xxxx.herokuapp.com,
Now, here's the issue, I need to set cookies between xxxx and yyyy, I know this will be a massive security issue but since this is an experimental website I am not willing to get a custom domain, I tried to set the cookies' domain to: herokuapp.com, .herokuapp.com, *.herokuapp.com, xxxx.herokuapp.com, yyyy.herokuapp.com.
Yet it doesn't work, chrome denies the cookies and gives this message:
This attempt to set a cookie via a Set-Cookie header was blocked because its Domain attribute was invalid with regards to the current host url.
So, how do I approach this issue without the need for a custom domain?
this is my configuration to set cookies (on the back end which uses flask)
response.set_cookie("example_cookie", value="cookie value",
max_age=900, expires=datetime.datetime.utcnow() +
datetime.timedelta(seconds=900), secure=True, domain=".herokuapp.com",
samesite='none')
If herokuapp.com were not a public suffix (a.k.a. an effective top-level domain or eTLD), then in the case of a cookie set by xxxx.herokuapp.com with Domain=herokuapp.com, browsers would send that cookie to yyyy.herokuapp.com
However, there is a snag: in order to isolate its different tenants, Heroku required herokuapp.com be added to the public-suffix list a while back. Most browsers refuse to set a cookie for a public suffix:
For security reasons, many user agents are configured to reject Domain attributes that correspond to “public suffixes”. For example, some user agents will reject Domain attributes of “com” or “co.uk”.
Therefore, attempts to set a cookie with Domain=herokuapp.com will be rejected by browsers, as you've experienced.
Note: adding a leading dot in the Domain attribute of the Set-Cookie HTTP header has no effect, at least in modern browsers.
To get out of this difficulty, you could simply buy a cheap domain name (say infinityvive.com) to serve both your frontend and backend from subdomains of it. Then you'd be able to use Domain=infinityvive.com because your domain would not be a public suffix.
I am managing two separate apps through two different Heroku pipelines.
App 1 - Handles my auth, this is a login landing page.
App 2 - The main app, can access after authenticating via App 1.
I have separate review apps running for each app. The reasoning was so I can have both Review
Apps under the .herokuapp.com domain.
App 1 takes Username, Password, and sets a JWT. In App 1, a query param is set and it contains a callbackUrl to App2. The JWT is set as a cookie in App 1 and sent to App 2 via a cookie (a token).
This is a problem with the new Same-Site Rules in Chrome. However, I have read various articles and workarounds for this, and my Cookies are still blocked. Here is the error:
the Set-Cookie was blocked because its domain attribute was invalid with regards to the current host url.
I believe they are blocked because the domain .herokuapp.com is on the Public Suffix List, so no matter what I do, they will always be blocked.
Is there a workaround for this? Can I use my own domain with a review app? Ideally:
app1.helloworld.com
app2.helloworld.com
.helloworld.com would be the domain.
Indeed they are blocked due to the domain being on suffix.
But you can block chrome from registering that you are on the suffix list through creating a library with automated deployments similar to hstspreload and then also providing a mechanism that any HTTP library can update the packaged list via their own fetching mechanism.
sadly you cannot reliably exclude .herokuapp.com from the suffix list or any other website for that matter.
for those wanting to see more about attempting to remove from suffix, here are the pros and cons and other theorized attempts:
https://forum.blocsapp.com/t/remove-html-suffix/1643
We need to have some modules, for example: admin, app API, website.
So, for website URL is https://company-name.com. For modules we want https://admin.company-name.com and https://api.company-name.com.
How we can make subdomains secure(https). To use same certificates as for website, or they should be separately new certificates? What issues we can have if we will use same certificates?
You need an certificat which include all your domains and subdomains on the SAN ( Subject Alternative Name ) field of your certificat. The simplest way ist to use lets encrypt, which generate it for free.
Than you include this certificate on both virtuell hosts
You can use cert-bot to get https certificate
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04
Just add all domains while executing.. so, your certificate will remain valid on all the mentioned sub-domains
certbot --apache -d example.com -d admin.example.com -d api.example.com
I have an api project written using laravel which uses passport to generate api tokens. These tokens are used to distinguish who is hitting my routes so that the appropriate data is returned. All of this is working currently.
Both the token generation screens and api routes are contained within the same project. So hitting:
example.com
Brings you to the login screen. Once you log in, you generate a token and then use that token in subsequent requests to the api routes. The token is included when making requests for:
example.com/api/route1
example.com/api/route2/id1
Etc.
Toward the end of the project a requirement has come up to increase the security of the login page. I would like to generate a client certificate that I provide to my users that is necessary for accessing the login page.
How would I do this without affecting how I have the api routes setup? In other words, I am looking to have a workflow for users like this:
import certificate into browser
Now that certificate is installed, user can access login page
login, generate token
use token to make programmtic calls to api routes. These calls should not require the landing page certificate.
Is this possible? Or will adding the client certificate for logins affect the api routes as well?
Thanks for any advice.
You could wrap your routes which require a certificate around a middleware. This middleware should to check if the certificate is installed otherwise redirect them to the pages accordingly.
Checkout the docs
https://laravel.com/docs/5.4/routing#route-group-middleware
and
https://laravel.com/docs/5.4/middleware#assigning-middleware-to-routes
You can also use gates and policies for certain actions: https://laravel.com/docs/5.4/authorization
Lets say a user can update a post, but cant delete it. Those policies are helpfull for it
I'm building a Sinatra app which needs to use a session variable for one very specific thing. The session variable is set when the user is looking at an SSL enabled page.
I'm using Heroku's piggyback SSL, so the SSL url is something like https://myapp.heroku.com
However, the app itself is hosted at my url, myapp.com
Is there a way to make my session variable, which is set while on the ssl / heroku domain name, available to my app while while on my domain name?
Unfortunately no, since the cookie is tied to the domain. What you'll have to do is either allow authenticated users to use the https://foo.heroku.com domain, and reserve your nice domain for the landing page & other unauthenticated pages.
That, or pay $20 for heroku's SSL add-on.
(I ran into this exact problem in http://appkickstand.com and I chose to just deal with the heroku url for logged in users)
You should look for cross-domain cookies manuals, check this.
But i don't see many reason in setting cookie through secured channel and transmitting it later via raw HTTP, where everyone could sniff it.