pytwitcherapi.oauth

Twitch.tv uses OAuth2 for authorization. We use the Implicit Grant Workflow. The user has to visit an authorization site, login, authorize PyTwitcher. Once he allows PyTwitcher, twitch will redirect him to pytwitcherapi.REDIRECT_URI. In the url fragment, there is the access token.

This module features a server, that will respond to the redirection of the user. So if twitch is redirecting to pytwitcherapi.REDIRECT_URI, the server is gonna send a website, which will extract the access token, send it as a post request and give the user a response, that everything worked.

Classes

LoginServer(session)	This server responds to the redirection of the user after he granted authorization.
RedirectHandler(request, client_address, server)	This request handler will handle the redirection of the user when he grants authorization to PyTwitcher and twitch redirects him.
TwitchOAuthClient(client_id[, ...])	This is a client needed for oauthlib.oauth2.OAuth2Session.

Data

log	Instances of the Logger class represent a single logging channel.

pytwitcherapi.oauth.log = <logging.Logger object>

Instances of the Logger class represent a single logging channel. A “logging channel” indicates an area of an application. Exactly how an “area” is defined is up to the application developer. Since an application can have any number of areas, logging channels are identified by a unique string. Application areas can be nested (e.g. an area of “input processing” might include sub-areas “read CSV files”, “read XLS files” and “read Gnumeric files”). To cater for this natural nesting, channel names are organized into a namespace hierarchy where levels are separated by periods, much like the Java or Python package namespace. So in the instance given above, channel names might be “input” for the upper level, and “input.csv”, “input.xls” and “input.gnu” for the sub-levels. There is no arbitrary limit to the depth of nesting.