I have a question, so im currently building back-end less app with firebase( auth and database).
So, my question is how will work if my hosting is different(for example: superhosting.bg).If upload my app there,what should i need to run properly my app ?Can you explain me a little bit?
Firebase requires you to use Google servers. You cannot run firebase outside of Google's server-side environment. However, since you mentioned backendless (full disclosure - I am the founder), if you were to build your app with it, you can run it anywhere where Docker/Kubernetes runs.
Firebase Authentication and Realtime Database can be used from any hosting provider. There is no need to host your web site on Firebase Hosting. Just follow the setup instructions (ignoring the ones for Firebase Hosting), and you'll be good to go.
What do you actually want to transfer to superhosting.bg - you want to use a superhosting-owned domain to attach your app to or you want to use their hosting?
As Frank van Puffelen answered above, for the latter just follow bith platforms' instructions on set up. However, if you're already using firebase, I'd stick with that.
For using custom domain on superhosting with firebase, you need to add the TXT records shown in firebase to your DNS provider (superhosting). Essentially, you will need to edit the DNS Zone of your domain.
In superhosting this is done through their cPanel. Then you go to DNS zone editor and find the domain you want to edit. Once here, you have to option to add TXT registry.
To get this TXT registry, go to Add Custom Domain in firebase (docs here: https://firebase.google.com/docs/hosting/custom-domain). They'll give you a TXT code you copy in the aforementioned location in cPanel.
Et voila!
Related
I hosted a static page using Free Firebase Hosting, but found that if I used www. Before the full URL, the browser says "Privacy Error" and this could scare my customers.
✔️ example.web.app - Works
❌ www.example.web.app - Doesn't work
Error message screenshot
For context, I'm a student and decided to use Firebase because their hosting is free, up to an extent. I read that I could fix this error message by buying a domain but that for me would defeat the purpose of using Firebase in the first place.
For more context, the problem is that the design studio we hired messed up and printed the wrong URL. Now we have a bunch of useless pamphlets that say www.example.web.app.
TL;DR. Is there a way to redirect www.example.web.app to example.web.app?
Preferably explain as if I were 5, Firebase and Hosting in general is too new for me.
Thanks in advance.
If you're using the domain assigned to you by Firebase (*.web.app), know that you can't change the way that domain works. It's fully under control by Firebase and maintained automatically for free as a convenience for you.
If you want control over your site's name in the URL, you will need to connect your own domain that you purchase from some DNS provider.
Our app hosted on firebase hosting is currently updated via firebase CLI. However, our app may get a feature where a user can create some custom static web files and upload a zip file containing those files to our site, after which these files are available as part of the site. (like a wiki/news article). For example: if a user uploads a zip file file which contains an index.html and some images that are linked to the html file, then the site will get updated with these materials and will show them at: oursite.com/username/somearticle/index.html
Through info gathered via this page , it appears that using the Hosting REST API would be able to get the job done. However I have a few questions about the functionality offered by this solution:
To start using the API, we firstly need an access token to authenticate and authorize API requests. Is there a way to get this token for a standard user who's logged in to our site using firebase authentication?
It says in this part of the article that you need the list of all currently existing files and new files in order to update the site. How do I access the list of files that are currently a part of the site?
On a similar note like the above question, we may need to update the app functionality from time to time and those updates are done via the CLI. How do I ensure that these functionality updates don't overwrite updates made by the user? In other words, is there a way to merge updates into the hosting site using CLI commands?
Firebase Authentication users don't have enough privileges to deploy to hosting. The users will need to be collaborators on the Firebase project, which means they'll need to have a Google account.
I recommend checking out my Gist that shows how to deploy a single files, which does something quite similar that what you're trying to accomplish. It gets the list of existing files (and their hashes) in this code fragment.
"When a user uploads a file" doesn't exactly sound alike "version control" to me ...
better use Cloud Source Repositories and add a Build Trigger, which deploys to Firebase Hosting.
Here it's explained: https://cloud.google.com/build/docs/deploying-builds/deploy-firebase
I mean, how else would you'd be able to keep a version history? And if you really want to upload something, just upload, unzip, also commit to git. HTML files are perfectly suitable for that.
The general idea is to have a continuous version history, which automatically deploys itself on change.
I have a Vue.js app and use Firebase Hosting to serve the static files to users.
Does Firebase Hosting have a method for putting the app into maintenance mode remotely? Without having to do firebase deploy
Maybe something that will allow me to redirect all the traffic to some other index.html, and be able to manage it from Firebase.
P.S. I've already looked into Firebase Remote Config (and it doesn't fit my use case, and their web related tools aren't fully implemented yet). And I'd like to avoid having a realtime database just for maintenance mode.
There is no mode-switch built into Firebase Hosting for temporarily serving other content.
But given the recent updates to deploy efficiency, it should be pretty low-cost to put up a temporary index.html while making the changes. Alternatively, you could deploy rules (in firebase.json) that temporarily redirect all traffic to a wip.html (for work-in-progress).
Which of these works best, depends on your current content structure. I.e. if you already redirect "all" traffic to index.html, I'd probably go with a rewriting solution.
You can also unroll your last deploy in one command.
Deploy maintenance page
Unroll when its done
Don't forget to send a 503 error for googlebot, asking it to come back in X hours.
If I publish my app to a subdomain, eg: spartan.meteor.com do I own the subdomain or can some other user take it from me? If I can own it, is there some documentation around it?
You can set a deploy password for your app.
$ meteor deploy -P spartan.meteor.com
Any future deploy (or request for logs) will require the same password.
As an update:
As of Meteor v0.7.1, this is no longer relevant. If you don't yet have a meteor developer account, meteor deploy <site> will prompt you for your email address and send you a link to create a password. Then they have some functionality around authorizing other users to collaborate on your app.
I believe it is now:
meteor deploy <site> [--password]
Your question also asked if there was any documentation. It is available here: http://docs.meteor.com/#meteordeploy
It covers additional things like changing the password. It specifies --password as the command-line option, but -P appears to still work. It alludes to forthcoming Meteor accounts.
I think this question was about the subdomain (SPARTAN) in meteor deploy domain (SPARTAN.METEOR.COM) being your property or not.
I've made a deploy half year ago and it's still there, so I think Meteor recycles the subdomains from time to time, but they give you a very good long time for sure.
I would like to create a sandbox area on my hosting provider that only the client can see. For example the production website would be at www.domain.com. However, would it be possible to create a sandbox version of the website at www.domain.com/sandbox and only provide access to the client?
If so, what is the best method? Do I manually have to create a login page etc in the sandbox folder? Or, can I publish the test website in the sandbox area and restrict access through my hosting provider?
Generally a sandbox/staging/test version of your production site would be a complete duplicate of your production deployment, not just the login page.
You'd have a separate copy of the application and the database, and then serve it via another hostname/IP address or on an entirely different machine.
For instance, you could have www.domain.com and test.domain.com, each with the own isolated version of the software. This way your client can play as much as they want in the sandbox without fear of damaging the production environment.
To restrict access you could use access control lists in IIS to restrict the sandbox to a specific ip address (or range), or enable basic support on it with a username/password required security.