I can't seem to find documentation of how to accomplish this. I'm requiring Facebook login and deploying to a meteor.com subdomain. I would like to have a settings.json file (or some other way) of recognizing the environment and providing the correct FB App configuration details.
Thanks.
Use the process.env variable to see what's your environment and swith between settings. For example, the provess.env.ROOT_URL to bring http://localhost:3000 as a result.
See the node js docs here
Related
As the title suggests - I have a nextjs application that works absolutely fine locally - However, now I've deployed it to a dev environment, something really weird is happening.
I've deployed my application to a dev environment, and set my NEXTAUTH_URL Environment Variable to my development domain dev.mydomain.com. However when I login it redirects me to localhost:3000 . The weird thing is, if I have my local server running, and I change the port it runs on to say :4000, the actual website redirects me to localhost:4000... It's like it knows where my code is running locally with no reference to it?
Does anyone know what's going on here? I'm very confused - There's no reference to localhost in my codebase whatsoever, never mind the specific ports!
Make sure to include "site" as a key in the object you pass to NextAuth, with the value of your environmental variable. For example:
NextAuth({site: process.env.NEXTAUTH_URL, providers: [...] })
Don't forget to add the site to your configuration of your NextAuth instance because I believe it redirects to localhost:3000 by default.
Be sure to add NEXTAUTH_URL to your env variable config on your cloud server.
I found the solution check your Auth Providor settings.
In my case, I use Github Provider and forgot to change my github oAuth App settings. Change two settings Home Url & callback url to your hosted base domain.
for example:
http://localhost:3000/ -> http://yourdomain.com/
Same for callback option.
Example
Make sure to redeploy your app after setting your environment variable NEXTAUTH_URL.
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!
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.
So I followed this tutorial to add logging to my project. Locally everything works fine, but when I deploy it to my staging environment and try to even visit the root page of the site I get a 403.14 Forbidden error saying that I need to enable Directory Browsing. I read somewhere that log4net uses a different user account to log and that could be causing issues. I was also thinking that it could be due to the location I am logging. I was hoping someone else had experienced this and could point out a solution.
The problem isn't with your code or Log4Net, it's with your hosting environment's default settings. Change the directory of the log file that is being written to a directory where you actually have rights, or change the access on the directory to which you are writing... Sounds like you're on a shared hosting server, and you usually need to manually enable whether or not a directory can have write access (ie: GoDaddy, etc). I've had this a few times and it was simple as that. This is why it was working locally (you have permissions to your own machine) and not once it was deployed.
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.