![]() ![]() To simplify developing, those could be loaded from scummvm.ini, but in ScummVM releases the other approach would be used.Īll Cloud-related methods require making a HTTP request to the provider's REST API (and even more than one request sometimes). Yet it means those are kept within application somewhere. Refresh_token=REFRESH_TOKEN&grant_type=refresh_token&client_id=KEY&client_secret=SECRET&redirect_uri=http%3A%2F%2Flocalhost%3A12345%2Fīoth KEY and SECRET are passed over HTTPS. Quite similar content is passed when we use it to refresh token: For example, the following OneDrive URL is used:Ĭode=CODE&grant_type=authorization_code&client_id=KEY&client_secret=SECRET&redirect_uri=http%3A%2F%2Flocalhost%3A12345%2F To get the access_token, application should do a HTTP POST to some special provider's "endpoint". Other providers usually give the token for an hour and provide an additional refresh_token which lasts longer and could be used to get new access_token when the previous is no longer valid. Dropbox has an "offline" scope, which makes that access_token last forever. When application gets the code, it should exchange it for an access_token. In this case user has to open a browser on the same device ScummVM is working on. Webserver is automatically started when Storage Connection Dialog is opened and stopped when it's closed. When "Allow" button is pressed on provider's site, user is redirected to " where ScummVM already waits for that code. The other way is starting a local webserver, which listens on a specific port (12345 to the moment) and awaits HTTP GET request with code passed. When user presses it, hashsum characters are removed and the passed code used to receive access_token. If no typos are detected, "Connect" button would be enabled. It automatically checks the hashsums, so if there is a typo, ScummVM would notify user about it. The Storage Connection Dialog then contains 8 fields, where these short groups should be typed in. The first is using page, where the long code is automatically transformed into a few short groups with hashsum added. ScummVM supports two different ways to get that code. Providers usually show which scopes application wants to use, so we shouldn't ask for everything if we need only a few permissions ( list of scopes used). There different "scopes", which could help application to specify what they want to get access to (for example, application could be limited to read/write files only in a special directory). When they do, they'd see some information about the application and would be given a choice to allow or deny that application access to user's storage. When users open such link, they have to auth to the provider first. Response type "code" means that we want to get a code, not the actual access_token. We also specify a redirect_uri there, which is required to be either link, or a one. So, it's obvious that KEY is not a secret, and even called "id" in some providers. Developers can also specify some information about their applications (name, logo, description) and add permitted redirect_uris.Īpplication should navigate its users to a special link. Each application has a KEY and a SECRET strings. In order to do that, a special application has to be registered in the developers section of these providers. Basically, ScummVM uses REST APIs of the specified Cloud providers. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |