get Auth token with AppKey and Appsecret error

получается у этих долбоёбов еще и code тоже временная. Гады

What thread is there no intelligible manual? the user must open the browser and receive the code, from there paste it into the application, then use it once, and all over again?

It turns out that it is necessary to distribute access from the account to everyone ?

X9l0F84JUAAAAAAAAAAB8FhCxgouMy95JIjMG4GWLAM

дружище, помоги пожалуйста авторизацией, пару дней и на другой сервис все переделаю. Задолбало.

---

OLIM wrote:

... the user must open the browser and receive the code, from there paste it into the application, ...

---

This is one possibility. I chose such a flow for clarity and simplicity. As mentioned there, you can automate this process using redirection. Then you will receive the same code through request parameter and use it further in the same way.

---

OLIM wrote:

..., then use it once, ...

---

Yes, this is single "shot" code and once used can't be used anymore.

---

OLIM wrote:

..., and all over again?

---

No... You have to keep the refresh token and use it further on, as mentioned, not the initial code.

I do not know where to store this token. I can't control users in 3 countries when they want to update data from Dropbox. I just need a repository where some upload data and others update from there. And they don't necessarily have a Dropbox profile

---

OLIM wrote:

I do not know where to store this token. ...

---

Hm...🤔 really... 😁 Where you are keeping your application configurations? 🧐 ... different registry types, config file, some local wallet,... etc. 😉 The choice is yours! Most probably you have already made it if I have to bet, but you still don't understand it.

everyone runs it on their computers, everyone has separate copies, two types of everything, those who update the data, and those who download them. Previously, one token was, of course, hidden from the user, and there were no problems.

I am currently sitting in Lebanon, uploading data until morning, the token changes twice. The last token is saved on my computer. . And the user who is in Turkey starts work in the morning, and he still has the token that was yesterday.

Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention (that is, once the user authorizes the app once, they don't need to authorize the app in their browser again). You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.

While short-lived access tokens are temporary, refresh tokens are long-lived and don't expire automatically, like the previous long-lived access tokens. So, you can store and re-use refresh tokens like you may have previously done with long-lived access tokens. For reference, both with the process for previous long-lived access tokens and new short-lived access tokens/refresh tokens, note the "authorization codes" have and continue to be temporary single-use codes used during the authorization process.

As for examples, the HTTP documentation has examples shown in curl, but you can translate that for whatever platform you need. And for prototyping and trying out specific API calls, the API v2 Explorer can be helpful. It can even show you how the request would be formatted in multiple contexts, such as in Python or raw HTTP, if you click "Show Code". There are also official SDKs listed here, which each come with some examples.

Also, "oauth1_token" and "oauth1_token_secret" are parameter names for use with /2/auth/token/from_oauth1 only. That is only needed if you have previous OAuth 1 access tokens from the now-retired API v1 and need to convert them to OAuth 2 for API v2. It sounds like that's not the case in your scenario though so you shouldn't be using "oauth1_token" and "oauth1_token_secret" or /2/auth/token/from_oauth1.