TheCodingCompany/MastodonOAuthPHP

Do we have to do createApp every time we make a request?

Closed this issue · 14 comments

One thing I am a little confused on, is if we need to do the createApp step every time? As that seems to spam our Mastodon accounts with duplicated applications.

No you only need to grab an APP ID and Token 1 time. So the Create APP method should be executed 1 time only. You need to make sure you save those keys and tokens. Those you will always need.

How exactly do we post a status, once an app has already been created? The only actual example here is the whole process, not how you do it once it's done. I still find it ridiculous we have to "make" an app using a script too, Mastodon needs an actual UI for it like other networks.

Right now, here's how I'm posting to it:

require_once("autoload.php");

$t = new \theCodingCompany\Mastodon();

$token_info = $t->createApp("appname", "url");

$token_info = $t->getAccessToken(M_KEY);

$status = $t->authenticate(M_USERNAME, M_PASSWORD)->postStatus('status');

If I take out the "createApp" step it doesn't work, authentication fails, so how do we do it without it?

There's a lot that doesn't make sense, we're making and authenticating an "app", but all examples require a username and password as well, why? Are you mixing two completely different ways of authenticating together? If so, they need entirely splitting up, as it's confusing.

I think we need to split up the documentation on the example to show

  1. How to actually make and authenticate an app
  2. How to do anything once an app is made
  3. IF you are mixing up the two ways of doing it (app or user details), then split them up entirely

Right now the example is extremely confusing unless you know EXACTLY what you're doing.

The documentation here is ... sparse, so working out how to properly use this lib requires a fair amount of digging through the code. That's not optimal, and should probably be addressed.

That said, at the moment I'm only going to address this specific issue.

The flow should look something like this:

$t = new \theCodingCompany\Mastodon($domain);

if (have_creds($domain)) {
    $t->setCredentials(get_creds($domain));
} else {
    store_creds($domain, $t->createApp("appname", "url"));
}

// Other logic

Where have_creds(), get_creds(), and store_creds() are app-specific functions that access a data store of some kind, and can be simplified to drop $domain if you aren't connecting to multiple instances.

Hi sorry for that. For me its pretty selfexplaining code. But ok, we are not all the same. I will update the Readme.md file. Just give me a sec.

@digitalhuman as always, if you're doing something to help others, you need to think like others ;). We all think our code is easy to understand, but for someone completely new to it, it's likely another world :)

Thanks to @danhunsaker for attempting to help there. It would also help if we knew exactly what "setCredentials" needed and in what format too (that function isn't even mentioned in the current readme!).

Thanks to @danhunsaker for attempting to help there. It would also help if we knew exactly what "setCredentials" needed and in what format too (that function isn't even mentioned in the current readme!).

It's just a simple array. Store the exact value you get from ->createApp() (you can serialize() or json_encode() it if you like), and then when you run through again, the value you pass to ->setCredentials() will be guaranteed correct.

@LiamDawe Yeah you are right. Its always hard to go back. Much easier to go forward. Anyway, I updated the 'README.MD'. It that more clear?

If you have changes to the file please provide them. Or create a pull request. I wrote this from the top of my head thus without testing (no time) . So please correct me were I am being wrong.

Okay, that does seem to be a vast improvement yes, good so far, but I think it could do with a little more. I've sent in a small request (EDIT: Okay now I've done the pull request woops) just to help people a little with storing their keys, i think it will go a long way to help confusion here.

Onto some other bits...

In Step 3 you say this:

  • The above '$token_info' will now be an array with the info like below. (If successfull)

Which doesn't seem correct. It does not return all three keys, it returns one new key which I assume is the bearer token?

Would you mind updating the readme, to have a Step 4, where the user can now use those keys from the previous steps to post a status?

Having that done, would then make this readme 100% useful straight away.

#DigitalHuman: You are right. Sorry, my bad

Okay, so I updated my pull request, which now includes a Step 4 of posting a status using these keys :)

Thanks a lot guys!

@LiamDawe Can you change the step 3 as well? I am stuck in a meeting here....

Done a new pull request which adjusts the text in Step 3 and also makes a bit of Step 4 a bit clearer

Edit: I've updated that pull request with more commits to make more of the readme crystal clear

Once accepted, this project will be much much easier to use 👍

Awesome, I see it's accepted, will close this now! I may continue contributing in future to help make it super easy for people to use 👍