<commit_before>"""
This module is intended to document the main interface with the OpenID
consumer libary.  The only part of the library which has to be used
and isn't documented in full here is the store required to create an
C{OpenIDConsumer instance}.  More on the abstract store type and
concrete implementations of it that are provided in the documentation
for the C{__init__} method of the C{OpenIDConsumer} class.


OVERVIEW
========

    The OpenID identity verification process most commonly uses the
    following steps, as visible to the user of this library:

    1. The user enters their OpenID into a field on the consumer's
       site, and hits some sort of log in button.

    2. The consumer site sends the browser a redirect, sending the
       browser to the identity server's site.

    3. The identity server's site sends the browser a redirect,
       sending the browser back to the consumer's site with the
       information necessary to confirm the user's identity.

    There are a lot of conditional extras in the process, but that is
    the basic flow of an OpenID login from the consumer's point of
    view.  The most important part of the flow to note is the
    consumer's site must handle two separate HTTP requests in order to
    perform the full identity check.


LIBRARY DESIGN
==============

    This consumer library is designed with that flow in mind.  Our
    goal is to make it as easy as possible to perform the above steps
    securely.

    Waiting on resolution of structure.


STORES AND DUMB MODE
====================

    OpenID is a protocol that works best when the consumer site is
    able to store some state.  This is the normal mode of operation
    for the protocol, and is sometimes referred to as smart mode.
    There is also a fallback mode, known as dumb mode, which is
    available when the consumer site is not able to store state.  This
    mode should be avoided when possible, as it leaves the
    implementation more vulnerable to replay attacks.

    The mode the library works in for normal operation* is determined
    by the store that it is given.  The store is an abstraction that
    handles the data that the consumer needs to manage between http
    requests in order to operate efficiently and securely.

    Several store implementation are provided, and the interface is
    fully documented so that custom stores can be used as well.  See
    the documentation for the C{OpenIDConsumer} class for more
    information on the interface for stores.  The concrete
    implementations that are provided allow the consumer site to store
    the necessary data in several different ways: in the filesystem,
    in a MySQL database, or in an SQLite database.

    There is an additional concrete store provided that puts the
    system in dumb mode.  This is not recommended, as it removes the
    library's ability to stop replay attacks reliably.  It still uses
    time-based checking to make replay attacks only possible within a
    small window, but they remain possible within that window.  This
    store should only be used if the consumer site has no way to store
    data between requests at all.

    *: There are fallback cases in the protocol, where even a consumer
    usually running in smart mode acts like it's in dumb mode for one
    request, but those cases are not the normal operation.
    Additionally, the fallback cases are much more secure than pure
    dumb mode, as they still are making use the consumer's ability to
    store state.


IMMEDIATE MODE
==============

    In the flow described above, there's a step which may occur if the
    user needs to confirm to the identity server that it's ok to
    authorize his or her identity.  The server may draw pages asking
    for information from the user before it redirects the browser back
    to the consumer's site.  This is generally transparent to the
    consumer site, so it is typically ignored as an implementation
    detail.

    There can be times, however, where the consumer site wants to get
    a response immediately.  When this is the case, the consumer can
    put the library in immediate mode.  In immediate mode, there is an
    extra response possible from the server, which is essentially the
    server reporting that it doesn't have enough information to answer
    the question yet.  In addition to saying that, the identity server
    provides a URL to which the user can be sent to provide the needed
    information and let the server finish handling the original
    request.


USING THIS LIBRARY
==================

    Waiting on resolution of structure.
"""

__all__ = ['SUCCESS', 'FAILURE', 'SETUP_NEEDED', 'OpenIDAuthRequest',
           'OpenIDConsumer']

from openid.consumer.impl import \
     SUCCESS, FAILURE, SETUP_NEEDED, OpenIDAuthRequest

class OpenIDConsumer(object):
    def __init__(self, fetcher=None, store=None, immediate=False):
        if fetcher is None:
            from openid.consumer.fetchers import getHTTPFetcher
            fetcher = getHTTPFetcher()<commit_msg>[project @ Make store non-optional]<commit_after>"""
This module is intended to document the main interface with the OpenID
consumer libary.  The only part of the library which has to be used
and isn't documented in full here is the store required to create an
C{OpenIDConsumer instance}.  More on the abstract store type and
concrete implementations of it that are provided in the documentation
for the C{__init__} method of the C{OpenIDConsumer} class.


OVERVIEW
========

    The OpenID identity verification process most commonly uses the
    following steps, as visible to the user of this library:

    1. The user enters their OpenID into a field on the consumer's
       site, and hits some sort of log in button.

    2. The consumer site sends the browser a redirect, sending the
       browser to the identity server's site.

    3. The identity server's site sends the browser a redirect,
       sending the browser back to the consumer's site with the
       information necessary to confirm the user's identity.

    There are a lot of conditional extras in the process, but that is
    the basic flow of an OpenID login from the consumer's point of
    view.  The most important part of the flow to note is the
    consumer's site must handle two separate HTTP requests in order to
    perform the full identity check.


LIBRARY DESIGN
==============

    This consumer library is designed with that flow in mind.  Our
    goal is to make it as easy as possible to perform the above steps
    securely.

    Waiting on resolution of structure.


STORES AND DUMB MODE
====================

    OpenID is a protocol that works best when the consumer site is
    able to store some state.  This is the normal mode of operation
    for the protocol, and is sometimes referred to as smart mode.
    There is also a fallback mode, known as dumb mode, which is
    available when the consumer site is not able to store state.  This
    mode should be avoided when possible, as it leaves the
    implementation more vulnerable to replay attacks.

    The mode the library works in for normal operation* is determined
    by the store that it is given.  The store is an abstraction that
    handles the data that the consumer needs to manage between http
    requests in order to operate efficiently and securely.

    Several store implementation are provided, and the interface is
    fully documented so that custom stores can be used as well.  See
    the documentation for the C{OpenIDConsumer} class for more
    information on the interface for stores.  The concrete
    implementations that are provided allow the consumer site to store
    the necessary data in several different ways: in the filesystem,
    in a MySQL database, or in an SQLite database.

    There is an additional concrete store provided that puts the
    system in dumb mode.  This is not recommended, as it removes the
    library's ability to stop replay attacks reliably.  It still uses
    time-based checking to make replay attacks only possible within a
    small window, but they remain possible within that window.  This
    store should only be used if the consumer site has no way to store
    data between requests at all.

    *: There are fallback cases in the protocol, where even a consumer
    usually running in smart mode acts like it's in dumb mode for one
    request, but those cases are not the normal operation.
    Additionally, the fallback cases are much more secure than pure
    dumb mode, as they still are making use the consumer's ability to
    store state.


IMMEDIATE MODE
==============

    In the flow described above, there's a step which may occur if the
    user needs to confirm to the identity server that it's ok to
    authorize his or her identity.  The server may draw pages asking
    for information from the user before it redirects the browser back
    to the consumer's site.  This is generally transparent to the
    consumer site, so it is typically ignored as an implementation
    detail.

    There can be times, however, where the consumer site wants to get
    a response immediately.  When this is the case, the consumer can
    put the library in immediate mode.  In immediate mode, there is an
    extra response possible from the server, which is essentially the
    server reporting that it doesn't have enough information to answer
    the question yet.  In addition to saying that, the identity server
    provides a URL to which the user can be sent to provide the needed
    information and let the server finish handling the original
    request.


USING THIS LIBRARY
==================

    Waiting on resolution of structure.
"""

__all__ = ['SUCCESS', 'FAILURE', 'SETUP_NEEDED', 'OpenIDAuthRequest',
           'OpenIDConsumer']

from openid.consumer.impl import \
     SUCCESS, FAILURE, SETUP_NEEDED, OpenIDAuthRequest

class OpenIDConsumer(object):
    def __init__(self, store, fetcher=None, immediate=False):
        if fetcher is None:
            from openid.consumer.fetchers import getHTTPFetcher
            fetcher = getHTTPFetcher()
{'fraction_non_alphanumeric': 0.042709867452135494, 'fraction_numerical': 0.000589101620029455, 'mean_word_length': 3.3197625106022053, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5602316', 'n_tokens_mistral': 2456, 'n_tokens_neox': 2354, 'n_words': 1504}