I'm working on figuring out how to deploy a custom version of Calypso that doesn't depend directly on wordpress.com, rather, it just uses the wordpress.com OAuth API. I've created a custom Dockerfile that is compatible with Heroku deploys, but now I need some advice.
Could I get some clarification on what a complete configuration file for a deployment like I described above might be (which variables should/should not be set)?
There also appears to be a custom configuration script sourced by the committed Dockerfile, but there is no documentation on what it does, or why it's necessary for a production Calypso Docker image - what does it do, and is it necessary for my case?
Here's what my current production config looks like:
{
"port": 3000,
"desktop_oauth_client_id": "xxxxxxxxx",
"desktop_oauth_client_secret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"desktop_oauth_token_endpoint": "https://public-api.wordpress.com/oauth2/token",
"features": {
"oauth": "true"
}
}
edit: for clarity
Everything goes great, until I try to start calypso in the built image:
Nevermind this, I figured out that NODE_ENV _and_ CALYPSO_ENV must be set when running node build/bundle-production.js
- I'm confused why it wasn't able to pick them up from the containers env though :/
Edit: I also needed to set NODE_PATH so that the server and client directories were in the module loading path
Glad you found what you needed. I don't know much about the Dockerfile, but I'm happy to _try_ to help if you get stuck again...
At this point, I'm not sure at all how to configure OAuth logins - any insights here?
What errors are you seeing? There are several things you need to know:
desktop_oauth_client_id
, desktop_oauth_client_secret
to the values for this key.You need to create a new app for your user and set the desktop_oauth_client_id, desktop_oauth_client_secret to the values for this key.
I've got these.
You can only log in using the account associated with this key
How come the application can't authorize other users? What good is this for anyone trying to deploy their own version?
Add calypso.localhost to the javascript origins for the key.
I've got this too
Ping on this - Is there no way to run Calypso on a custom domain (not wp.com) and have people sign in with their accounts to edit their sites?
@cadecairos not yet sorry, but this is definitively something we want to have in the near future!
Hey @Tug, what are the steps needed to make this happen? We're happy to help!
@simonwex Thanks a lot for offering your help. let's see ;)
At the moment Calypso is designed to talk to the WordPress.com API only, so it's mainly backend things we are currently working on. Once this is done we will probably enable OAuth as the default authentication on Calypso (or at least give credentials for multi-user applications).
In the long term I think a lot of people including myself would really like to see Calypso become a client for any WordPress installation, but we would probably need to wait first for a unification of the WordPress.com and WordPress.org API.
Anyway, if you are planning on using Calypso for your projects, we would be very interested to hear about your use case and gather your feedback. I believe this is one of the reason Calypso was released open-source so don't hesitate to contact us or participate in the discussions here on Github.
@Tug I'd love to fill you in. We're planning on a production-prototype of Calypso + wp.com to evaluate for use on most of our websites at the Mozilla Foundation. I'd also appreciate a few mins to pick your brain about the project and what your OS motivations are, etc. I think we're quite aligned and could do some interesting work together.
I've sent an email to the address listed in your GH profile!
Hi @simonwex and @cadecairos, I've worked on our authorization code in the past... caveat that I haven't touched it in a while, so my perspective may be a little stale.
To give some context, when calypso was an internal experiment, we had started with OAuth support before we implemented the current cookie-based approach. In the race to finish v1.0 we decided to drop OAuth support because we weren't using it regularly enough to keep it from getting stale and buggy. We always intended to come back to build this out, but we didn't get to it in time for open-sourcing, unfortunately.
In order to make OAuth useful for you, we have some work to do on the back-end. We treat Automattic-controlled domains and apps specially in certain places in our API. So we need to track down those exceptions and address them. We don't have anyone dedicated to this right now, but I will kick the bushes and see what we can do.
@rralian thanks for digging in to this! I'm going to hand this off to @cadecairos. Our hope is to get our prototype hacked together so we can test it with our users. It shows promise long-term and I think is a compelling use of the wp API.
I'm happy for @cadecairos and others on my team to spend some time here where it would benefit your project, too. I suspect there will be some challenging pieces considering that wp.com is a private project on its own timeline, but any way we can make this collaborative is appreciated!
@cadecairos do you have any suggestions for how we can move forward?
I'd be happy to help get Calypso ready to use Oauth. I'm still unfamiliar with the codebase, and would appreciate some direction about where to look and what tasks need getting done.
Should I open a new issue, to kick things off? Perhaps one is already open?
@cadecairos @simonwex apologies for the delay here and thanks for your interest in the project :)
To expand a bit on what @rralian mentioned above, we used to have oauth authentication that required the user granting permission for the app to work (normal oauth integration). We had to drop this because we needed to integrate with existing authentication flows in WP.com that were unaware of Calypso. The oauth implementation in existence is particular to the desktop app, and not the one appropriate to replicate.
It's been a concern of mine from before open sourcing the project to bring back this flow, because it's obviously the way anyone outside of WP.com would want to use it. There are a few areas that will break, but in general they are related to specific items like WP.com signup that shouldn't be much of a concern to you or other contributors.
I'm going to outline our previous oauth flow in a new pull request and we can see how it goes.
Follow along in #4506 for progress on this one. Thanks for the question and discussion.
Most helpful comment
Hi @simonwex and @cadecairos, I've worked on our authorization code in the past... caveat that I haven't touched it in a while, so my perspective may be a little stale.
To give some context, when calypso was an internal experiment, we had started with OAuth support before we implemented the current cookie-based approach. In the race to finish v1.0 we decided to drop OAuth support because we weren't using it regularly enough to keep it from getting stale and buggy. We always intended to come back to build this out, but we didn't get to it in time for open-sourcing, unfortunately.
In order to make OAuth useful for you, we have some work to do on the back-end. We treat Automattic-controlled domains and apps specially in certain places in our API. So we need to track down those exceptions and address them. We don't have anyone dedicated to this right now, but I will kick the bushes and see what we can do.