Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Не могли бы Вы ознакомиться с вопросом по ссылочкам и дать ответ, за который я Вам дам максимально возможные баллы и мою огромнейшую благодарность!
S>>https://stackoverflow.com/questions/54381095/is-there-a-simple-way-to-access-the-quickbooks-api-using-oauth2
S>Ответ на вопрос видел. С API quickbooks я не знаком, определить, является ли этот ответ оптимальным или хотя бы единственным, не могу.
S>>https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#obtain-the-access-token
S>Я получаю 403 forbidden.
Ну потому, что из России. Нужен ВПН.
S>>https://www.thecodehubs.com/how-to-fetch-access-token-from-quickbooks-online-using-c/
S>В целом, выглядит так, что ребята отказались от app-only authentication вслед за передовиками, которые обнаружили, что слишком многие рукожопы используют clent secret в недостаточно секьюрных обстоятельствах.
S>Поэтому требуют App+User — то есть даже неинтерактивному приложению нужно получать токен интерактивно.
S>Вопрос-то у вас в чём?
Ну во первых за что минус? Вопрос в том, что для получения кода или рефреш токена нужно их получать через браузер!
Суть такая, что если на постоянку использовать RefreshTokenAsync то возвращаются новый или переданный рефреш токен. Он же является он же используется и для авторизации.
Но может прилететь ракета и отключить интерне. А протухает он вроде 6 часов или пару суток.
То есть у них есть отсылка сообщений по адресу установленный при регистрации. На который отсылаются коды при авторизации через браузер!
Это бред, но вы с НС называете меня тупым!
Но можно было бы при регистрации создавать пару асимметричных ключей. И вспоминить про
Алису и Боба
Либо придумать любую другую авторизацию , но без интерактива. Еще раз изначально думали, что все будут работать через браузер. Однако оказалось, что это не удобно.
И при этом работают не интерактивно а через промежуточный сервис.
Но никто не озаботился использования надежной неинтерактивной авторизацией!
Step 14: Use access tokens to make API calls
Access tokens let your app send requests to our APIs.
Pass the access_token value in the Authorization header of requests each time your app calls an API. The value should always be: Authorization: bearer {AccessToken}
Access tokens are valid for 60 minutes (3,600 seconds). When they expire, use refresh tokens to refresh them. Learn more about access and refresh tokens.
Step 15: Refresh access tokens
Use refresh tokens to “refresh” expired access tokens. You can refresh access tokens without prompting users for permission.
If you’re creating an HTTPS/REST request manually
Create a POST request and use the latest refresh_token value from the most recent API server response.
Send requests to the token_endpoint (available in the discovery document) using the following parameters:
Request parameters for refresh tokens
Field Description Required
grant_type
This is defined in the OAuth 2.0 server specification.
It must have the value refresh_token.
Required
refresh_token The refresh_token value you exchanged the authorization code for. Required
