Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to authenticate/work with different host #26

Closed

Conversation

geekgonecrazy
Copy link

@geekgonecrazy geekgonecrazy commented Jan 21, 2019

Depends on: writeas/go-writeas#16 which stores the baseUrl when authenticating and then uses that for all other requests.

One thing I haven't been able to figure out is why the post doesn't work to writefreely instance.. Always returns a 401. I've verified its getting the token.. but looks like for some reason not matching.. because sql isn't getting a match.

@geekgonecrazy geekgonecrazy changed the title Add option to authenticate with different host Add option to authenticate/talk with different host Jan 21, 2019
@geekgonecrazy geekgonecrazy changed the title Add option to authenticate/talk with different host Add option to authenticate/work with different host Jan 21, 2019
@thebaer
Copy link
Member

thebaer commented May 26, 2019

Hey, thanks for taking a stab at this! It looks like a good start to WriteFreely support.

The reason posting doesn't work is because once you authenticate, the application exits and the token is cleared from memory. To get it to work, we'd need to persist the token to disk and then load it for any subsequent calls.

Beyond that, we'll likely want to support the CLI working with multiple instances from one machine, so we'd need to have a way to manage data across users and instances. I've outlined a way we might do that in T586.

Full support for any WriteFreely instance is going to take a good bit of work, including renaming the application and removing anonymous posting functionality. So I want to make sure we just get the CLI up-to-date with the V2 API (blogs and accounts) before we go down that path.

@geekgonecrazy
Copy link
Author

I recall tracing and verifying the token was picked up and passed along. For some reason server side wasn’t happy with actual payload.

At any rate definitely can close this one out then. Sounds like will have to happen as part of wider arching change. One best probably taken by someone more intimately familiar :)

@thebaer
Copy link
Member

thebaer commented May 26, 2019

Yep, no worries. Again I appreciate you taking a look at it! If you wanted to help out we'd welcome it -- we'd just want to coordinate the work a bit more. Let me know if so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants