Heroku provides a quite easy way to host simple websites (e.g. via Nodejs, Expressjs) by linking a (public) github reposiory. The result is available via the subdomain appname.herokuapp.com.
What is the juristic background for that (or are there any precedent cases), as for example in Germany every webpage needs to provide an imprint and a privacy statement which I assume not many repositories provide. I assume heroku is not responsible for the content of their domain, are they?
Related
I many articles where writers show how to deploy a Laravel app/website on shared hosting they discourage doing that. In some other quora questions where the answers state that it is possible but has some security risks. So what security risks does this practice implies.
The honest answer depends on the type of project and-or customer (agency vs interprise).
If you are working for a smaller project and there is no on-going development (extra possible invoicing) to it I will recommend using a shared hosting.
But if your budget is pretty high and that application needs to grow, handles sensitive user data, automated deployments, unit testing together with Docker and Vagrant for local development. I would recommend using AWS or digital ocean.
The biggest problem using AWS is that it pushes the responsibility to you in keeping the operating system and PHP-version up-to-date.
With interprise customers, I would recommend using services like:
Use a security scan (https://detectify.com/)
Use a Firewall (https://www.cloudflare.com/en-gb/)
Basically it all depends on the type of customer you are dealing with.
But for a really small / tiny projects, just use a shared hosting and basically never forget to use CSRF, ReCaptcha, throttling requests, ... Be smart about it.
I have been doing a lot of research on this and I can't seem to find a definitive answer. Obviously these days security is a big issue, hacks are going on all over the place of major companies that invest millions into security and they're still getting hacked.
I work on Laravel a lot and use shared hosting with Hostgator or some similar company of high report. Laravel comes with a built in function for encrypting database info and decrypting to the user when requested.
However, I have a question on how secure this ACTUALLY is. If someone gets into my cPanel, my app key which is used for encryption is right there in front of them. Granted, my cPanel password is the one that's auto-generated by Hostgator and it's complete jibberish with semicolons and alphanumeric strings all over, so it's not easy to guess.
But I'm trying to learn a little bit more about security. If my app key in my env file is locked securely behind my cPanel login, is Laravels built in "encrypt()" method "enough" to call an app "secure"? Is there other measures within Laravel or my host provider that could make it more secure than just tight passwords? Is there some sort of practice of referencing the app key through an external source that's not located in the cPanel area? So even if my cPanel got hacked, my app key wouldn't be in those files and get exposed?
I'm not a security expert, but there are a few points I can share from my experience in working at highly-secured companies.
First, Laravel itself is fine. You can generally trust open source software since it's transparent and security bugs get discovered and addressed early. So you don't need to improve Laravel, just use it as is, preferably an LTS version.
Then, CPanel is a liability. You should minimize weak points on your system, i.e. those that are externally accessible. Get a VPS or a private server and access it via an SSH, don't use tools like CPanel and PhpMyAdmin on it. The less software you have that talks to the outer world, the less vulnerable you are to bugs in that software.
In my current company the production server can only be accessed via SSH from a single IP address, the address of the dev server. So I log in to dev server first, and then log in from there to the prod. It denies all connections from all other IPs.
If you are limited to using CPanel or something similar, consider protecting the login page with HTTP Basic Auth, some hosting providers allow that.
You also want to keep your system and software up to date. Not too new either as that may have bugs that haven't been caught yet. Our devops prefer to have it a couple of minor versions behind, so that the community has time to test it out and get hacked for you.
That's all I know as a web-dev, sure enough there are special tools and ddos protection services but that's beyond a dev's concern imo. If you just follow these steps, you should be safe. Hope that helped a bit, cheers :)
My Heroku-app is being used by other people, on other websites then mine.
Is there a way that only my site can use the app?
I have a small site so i use a free account, this way my free "dynos" are gone very quick.
You have some options...
If your app or api is being used by javascript web apps in the browser then setting a CORS heading specifying your top level domain should do the trick.
If your app or api is being consumed by other servers or non-browser based processes then specifying an authentication process such as http basic (user/password) should restrict access to the set of clients that you control. If your service is successful then congratulations! Maybe you should scale up and start charging?
It seems like your goal is to stay in the free tier at Heroku.
Heroku starts your dynos triggered by the request coming in on their router mesh. This means every authentication or blocking technique inside your application will still lead to the dynos being started (that includes CORS).
Heroku itself doesn't give you configuration for their routing in the free/low-price tiers. If you pay for it, there is private spaces.
One possible solution is to have another layer over your app that does the authentication.
For example this could be:
cloudflare
Amazon CloudFront (not sure, with the Web Application Firewall)
other CDN
These will likely have a free tier that's enough for you, but also be rather complex to setup for a beginner.
I hope I could help you a little
We have a Java Spring application with lot's of contacts inside a database. Now we'd like to provide these contacts via CardDAV in order to access them via external devices.
As far as I understood CardDAV, it uses the 'well-known' protocol. Which means, it'll look up http://mydomain.com/.well-known/carddav
This might be a problem, because we have a Tomcat Server running, and multiple applications running on it and each of them should provide a CardDAV server. This means, our URLs look like:
http://mydomain.com/appOne/
http://mydomain.com/appTwo/
http://mydomain.com/appThree/
Each of those applications has a completely different set of users and data. Though each of those CardDAV repositories has to lookup its own data source and has to use its own authentication mechanism.
The question is of course: How can I get multiple different CardDAV servers with a single domain?
Btw: Is there any REAL information about CardDAV (not just WebDAV or is it all the same?!)?
For example I couldn't find anything about multiple repositories / access right restrictions. Maybe I want to have a single CardDAV server with multiple different Users, where each user has an own address book and there are some common address books.
The well-known url is used for clients to automatically discover the root of the carddav server, when a user just types in a domainname. You can only redirect to 1 server per domain, but you could setup multiple domains to redirect to multiple carddav servers.
If you can't use multiple sub-domains, you simply cannot use well-known. Instead, you will have to ask users to fill in a full url to their principal to setup their acccounts.
As to your question if there's 'real' information. rfc6352 is the official documentation. It's definitely a lot more than just WebDAV.
Effectively, iOS only supports well-known. If an iOS device cant connect via well-known it will allow the user to enter a complete principal address, BUT thats only AFTER displaying an error message to the user, at which point most users will give up.
However, the redirect occurs after authentication, so as long as you're able to authenticate at the root (eg with a username scheme that incorporates the sub-site, like 'appOne:brad') then you should be able to do it. Alternatively, as mentioned above, just use subdomains.
I am looking to roll a simple CMS with Ruby and preferably Sinatra. www.nestacms.com looks like a terrific candidate.
Some key objectives:
Allow business users to add/edit/remove pages (not via git but via app functionality)
Deploy on Heroku
As I understand, Nesta pages are generated by static page files in your deployment. Which is fine if you add via git and push to Heroku.
But if you're wanting to create pages (files) in a Heroku web app, this isn't possible due to Heroku's read-only file system.
Looking for help around:
Achieving objectives with Nesta and Heroku
Alternative approaches
Github has an editor to manipulate files and buttons to create/merge branches in browser.
You may want store your content related media on a cloud storage services (such as dropbox, google drive, cloudflare etc.) You also can connect/mount these storages like drives via WebDAV or some other tools depending on your prefered service provider & OS.
snap-ci offers free and easy to use integration service for automated tests and/or deployment (heroku or your VPS/server). When master branch changed github webhook triggers snap-ci and your website will deploy in average 1 minute.