reuses oauth application IDs even after base_url property is changed

[velartrill]

any attempt to connect to a pleroma instance will result in an "invalid user/password" error. this appears to be because bitlbee-mastodon does not properly register an application with the server, and seems to just use a fixed client ID with all servers. to register an application, bitlbee should send a POST request to https://$instance/api/v1/apps with header Content-Type: x-www-form-urlencoded and POST content

client_name=bitlbee&redirect_uris=$REDIRECTURL&scopes=read+write+follow&website=https://bitlbee.org

this will return a JSON-encoded response, containing the client ID bitlbee should connect with as well as the secret it should use to communicate with the server.

[kensanata]

I fear that even this were resolved it wouldn’t work for Pleroma because the plugin doesn’t do web sockets. https://alexschroeder.ch/software/Support_Websockets_for_Streaming As I don’t use Pleroma, any help is appreciated.

Am 25.10.2019 um 14:36 schrieb Lexi Hale notifications@github.com:

 any attempt to connect to a pleroma instance will result in an "invalid user/password" error. this appears to be because bitlbee-mastodon does not properly register an application with the server, and seems to just use a fixed client ID with all servers. to register an application, bitlbee should send a POST request to https://$instance/api/v1/apps with header Content-Type: x-www-form-urlencoded and POST content

client_name=bitlbee&redirect_uris=$REDIRECTURL&scopes=read+write+follow&website=https://bitlbee.org this will return a JSON-encoded response, containing the client ID bitlbee should connect with as well as the secret it should use to communicate with the server.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[velartrill]

pleroma uses exactly the same API that mastodon does, with a few additions - almost all mastodon clients work out of the box with pleroma, so i don't think you need to worry about websockets. if there are no other streaming methods available, we could just have it poll at configurable interval the way the bitlbee twitter module currently works - it's not perfect but it's serviceable

(sidenote: thank you for the fast response! this is the first response to a bug report i've gotten in months.)

[velartrill]

…i wish i'd thought to check this before i filed the bug report.

bitlbee-mastodon is actually registering itself completely correctly. the problem was that i didn't know i needed to change the base_url property until i tried to connected, and it pointed me at octodon.social. it cached the app id, and tried to use the same one after i set the base_url to pleroma.social. deleting and re-creating the account with the proper base_url fixed the problem, but revealed a new one:

Topic for #pleroma.site_velartrill is "BitlBee groupchat: "mastodon/timeline". Please keep in mind that root-commands won't work here. Have fun!"
Topic set by root!root@hale.su on 2019-10-25 13:00:17 UTC
Mode #pleroma.site_velartrill +t by hale.su
root has kicked lexi from #pleroma.site_velartrill (Chatroom closed by server)

i assume this is related to the streaming problem?

[kensanata]

I actually don’t know the exact behavior when running into the problem. As far as the streaming API goes, the thing is that there are actually two of them, and Pleroma just implements one of them, and Bitlbee-mastodon implements the other, unfortunately. I think I heard it from one of the devs themselves but didn’t save the url to the toot. :)

[velartrill]

ahh yeah, that explains the error message. would you be open to a PR that implements polling instead of streaming for pleroma servers? i may give it a shot if so

[kensanata]

I think we don't want polling but websockets. I'd be interested in getting that added to Bitlbee Mastodon!

See WebSocket Documentation for Mastodon. Perhaps you should verify that this is in fact what Pleroma implements, just to be sure.

Note that the Discord Plugin for Bitlbee has Websocket support, so looking at discord-websockets.c would be a good start, I think.

[kensanata]

As for this particular issue, I'm guessing that we could do the following:

• in mastodon_init don't use NULL as the evaluation function but use our own
• write this new function which does nothing but set md->oauth2_service->consumer_key and md->oauth2_service->consumer_secret to the empty string "" again

An example can be seen at the end of mastodon_init:

    s = set_add(&acc->set, "consumer_key", "", NULL, acc);
    s = set_add(&acc->set, "consumer_secret", "", NULL, acc);

An example of how these functions work is set_eval_commands. We would probably want something like this:

static char *set_eval_base_url(set_t * set, char *value)
{
    s = set_add(&acc->set, "consumer_key", "", NULL, acc);
    s = set_add(&acc->set, "consumer_secret", "", NULL, acc);
    return value;
}

This would ensure that on the next call to mastodon_login our mastodon_register_app gets called again.

[velartrill]

another thing to consider might be using the "server" parameter in the "account add" command to specify the base url, so users don't have to fix the setting by hand and can just enter one at account creation. the current design is slightly confusing

i'll open a new issue for the pleroma integration thing.

[kensanata]

I wasn’t aware of a server parameter. It sounds just like the thing we need.

[velartrill]

i'm not actually totally certain it's still there - the help command for account add only mentions username and password fields, but the quickstart guide describes the syntax as

To add an account to the account list you will need to use the account add command: account add <protocol> <username> <password> [<server>].

whichever accurately describes the syntax, we should probably open a ticket with the bitlbee project to correct the help/quickstart text. :)

the syntax described by the quickstart guide presents an obvious problem - you can't specify a server without also specifying a password, which oauth doesn't use. two possibilities come to mind: either having the user pass a faux password like . or something and ignoring it, which is kind of inelegant, or just abusing the password field - if the server field is blank, assume the password field contains a server address.

of course, we could allow the user to enter their real password, and make an http request to perform oauth directly in the plugin, which would be considerably friendlier than the current mechanism. in this case, it would be nice to preserve the current behavior in the case of a blank password - it would allow users who aren't running their own bitlbee servers to authenticate without handing over their account password to a potentially malicious actor. (there's an argument to be made that doing this encourages the user to supply their password in unsafe circumstances, but bitlbee itself already encourages this and there's not much a plugin can do about it - anyone who doesn't already understand oauth is likely to supply their password when creating an account with the mastodon plugin, or twitter plugin for that matter.)

what may be the best option though is simply incorporating the server address in the username - if the user enters an address like velartrill@pleroma.site, we can generally assume that the base_url will be https://pleroma.site/api/v1/, and it's less unreasonable to expect the user to change the base_url property if their server places its API endpoint in an unusual location.

(we could also implement some mix of these options and select one based on the information supplied by the user, which would probably present the best UX, since we can't necessarily instruct the user on the "correct" means to add a fediverse account before they do so.)

[kensanata]

I like the solution of the user supplying their account and us deriving username and instance from it. That would work.

I also think asking for the real password defeats the purpose of OAuth: users getting to use an application without divulging their real password.

[velartrill]

i agree, it does defeat the purpose of oauth, but bitlbee already encourages users to divulge their password and i don't think there's much that can be done about that. given the number of people who run their own private bitlbee instances on localhost, it doesn't seem unreasonable to give them the choice, or at least behave as expected if they type an account add mastodon user@web.site hunter2 command to create their account, in which case the damage is already done.

that's tangential to this issue however - i'd be happy to submit a PR to derive the the base_url from the username field if you'd like.

On Saturday, October 26, 2019, Alex Schroeder wrote:

I like the solution of the user supplying their account and us deriving username and instance from it. That would work.

I also think asking for the real password defeats the purpose of OAuth: users getting to use an application without divulging their real password.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/kensanata/bitlbee-mastodon/issues/36#issuecomment-54664656

[kensanata]

I’ll be happy to take that PR. 😀

[kensanata]

I think the original issue has been resolved and we can close this? Sure, Pleroma still doesn't work because we're lacking the websocket stuff, but we track this in #37.

[velartrill]

agreed