Saravanan666/pypi-org huggingface dataset:
Package: repoze.what.plugins.ip
It is arepoze.whatplugin that provides an ip_from predicate.Installationeasy_install:$ <env>/bin/easy_install repoze.what.plugins.ippip:$ <env>/bin/pip install repoze.what.plugins.ipSourceThe source code can be found atcode.google.com.Usageip_from([allowed=None],[proxies=None])checks whether REMOTE_ADDR in the
environment points to an allowed IP address. If HTTP_X_FORWARDED_FOR is set
in the environment (meaning proxy access) then REMOTE_ADDR is treated as a proxy
address and HTTP_X_FORWARDED_FOR as an originating IP address.allowedoptional, default -NoneA list of IPs to allow access. Can be a string which is then interpreted as
a single IP addressproxiesoptional, default -NoneIf a list or tuple provided then treated as a list of authorized proxy IP
addresses.If a string or unicode provided then treated as a single IP address.Any other value -bool(proxies) == Truemeans that all proxies are
acceptedYou can filter the incoming IP address:>>> from repoze.what.plugins.ip import ip_from
>>> p = ip_from(allowed=['192.168.1.1'])
>>> env = {'REMOTE_ADDR': '192.168.1.1'}
>>> p.is_met(env)
True
>>> env = {'REMOTE_ADDR': '192.168.1.10'}
>>> p.is_met(env)
FalseBy default proxy access is disabled. You can enable it withproxies=True:>>> p = ip_from(allowed=['192.168.0.0/24'], proxies=True)
>>> env = {
...     'REMOTE_ADDR': '192.168.1.1',           # proxy
...     'HTTP_X_FORWARDED_FOR': '192.168.1.5'   # origin
... }
>>> p.is_met(env)
TrueAnd you can also explicitly specify proxies to allow:>>> p = ip_from(allowed='192.168.1.5', proxies=['192.168.0.0/24'])
>>> env = {
...     'REMOTE_ADDR': '192.168.1.1',           # proxy
...     'HTTP_X_FORWARDED_FOR': '192.168.1.5'   # origin
... }
>>> p.is_met(env)
True
Package: repoze.what.plugins.redis
This is an adapters plugin forrepoze.whatThe Redis plugin makesrepoze.whatsupport sources defined in Redis key-value
databases by providing one group adapter and one permission adapter.RedisRedisis a key-value database. It is
similar to memcached but the dataset is not volatile, and values can be strings,
exactly like in memcached, but also lists and sets with atomic operations
to push/pop elements.In order to be very fast but at the same time persistent the whole dataset
is taken in memory and from time to time and/or when a number of changes
to the dataset are performed it is written asynchronously on disk.The database name is numeric; the default database is0.repoze.what.plugin.redisuses database1for the group adapter and
database2for the permission adapter.The database0could be used for any table related to users as the sessions.BuildingTo compile the trunk version:$ git clone git://github.com/antirez/redis.git
$ cd redis
$ makeTo update:$ git pull && make clean && makeTo run the server:$ ./redis-serverThe Python library is in./client-libraries/python/Note: The client-libraries directory inside the Redis distribution is
only a temp thing.Little issuesIf the client is disconnected after of some time of inactivity –it’s
configured to 300 seconds by default–, and it’s called any command then
it raises aConnectionError. It should be rather managed from the Python driver:http://groups.google.com/group/redis-db/browse_thread/thread/2581396a6722d3f9The data are synchronously saved. It could be modified the_savefunction
(in the Redis adapter) for that it been asynchronously saved, or for that
it been saved only when a number of changes to the dataset are performed.UseTypical usage:>>> import redis
>>> from repoze.what.plugins.redis import adapters>>> group = adapters.RedisGroupAdapter(redis.Redis())
>>> permission = adapters.RedisPermissionAdapter(redis.Redis())
Package: repoze.what.plugins.xml
**************************The repoze.what XML plugin**************************This is an adapters plugin for repoze.what.Supported source formats========================A sample group source may look like this::<?xml version="1.0" encoding="UTF-8"?><groups><group name="admins"><member name="rms" /></group><group name="developers"><member name="rms" /><member name="linus" /></group><group name="trolls"><member name="sballmer" /></group><group name="python"><!-- An empty group --></group><group name="php"><!-- An empty group --></group></groups>A sample permission source may look like this::<?xml version="1.0" encoding="UTF-8"?><permissions><permission name="edit-site"><group name="admins" /><group name="developers" /></permission><permission name="commit"><group name="developers" /></permission><permission name="see-site"><group name="trolls" /></permission></permissions>
Package: repoze.what-pylons
This is an extras plugin for repoze.what which provides optional and handy
utilities for Pylons applications using this authorization framework.Some of the features of the plugin include:The utilities are ready to use: There’s nothing additional to be
configured before using.100% documented. Each component is documented along with code samples.The test suite has a coverage of 100% and it will never decrease – if
it ever does, report it as a bug!TurboGears 2 is officially supported as well.
Package: repoze.what-quickstart
This is an extras plugin for repoze.what.This plugin allows you to take advantage of a rather simple, and usual,
authentication and authorization setup, in which the users’ data, the groups
and the permissions used in the application are all stored in a SQLAlchemy
or Elixir-managed database.Put simply, it configures repoze.who and repoze.what in one go so that you
can have an authentication and authorization system working quickly – hence
the name.
Package: repoze.who.cas
Introductionrepoze.who.cas is a repoze.who plugin that allows the use of aCAS
<http://www.jasig.org/cas)server as an authentication provider. It allows you
to specify a CAS server against which your users can authenticate. Once they
authenticate against the CAS server, they’ll be redirected to your application
in such a way that their identity will be injected into the WSGI environment
with a key that you can specify.Example who.ini[plugin:cas]
use = repoze.who.plugins.cas:make_plugin
cookie_name = someapp-cas
secret = ahardtoguessthing
cas_login_url = https://cas.example.com/login
cas_validate_url = https://cas.example.com/validate[general]
request_classifier = repoze.who.classifiers:default_request_classifier
challenge_decider = repoze.who.classifiers:default_challenge_decider
remote_user_key = REMOTE_USER[identifiers]
plugins = cas[authenticators]
plugins = cas[challengers]
plugins = cas
Package: repoze.who.deprecatedplugins
``repoze.who`` -- WSGI Authentication Middleware / API======================================================Overview--------``repoze.who`` is an identification and authentication frameworkfor arbitrary WSGI applications.  ``repoze.who`` can be configuredeither as WSGI middleware or as an API for use by an application.The plugins in this package were originally distributed with ``repoze.who``,but are now deprecated, and released separately to discourage theiruse in non-legacy deployments.repoze.who.deprecatedplugins Changelog====================2.0 (2010-09-30)----------------- Broke out the deprecated ``repoze.who.plugins.form`` and``repoze.who.plugins.cookie`` modules from the ``repoze.who`` trunk.All plugins in this project are deprecated.
Package: repoze.who.plugins.digestauth
This is repoze.who plugin implementing HTTP’s Digest Access Authentication
as per RFC-2617:http://tools.ietf.org/html/rfc2617It provides good support for the protocol as it is typically used in the
wild:both qop=”auth” and qop=”auth-int” modescompatability mode for legacy clientsclient nonce-count checkingnext-nonce generation via the Authentication-Info headerThe following features of the protocol are rarely supported by HTTP clients
and thus have not yet been implemented:MD5-sess, or any hash algorithm other than MD5mutual authentication via the Authentication-Info headerConfigurationConfiguration of the digest-auth plugin can be done from the standard
repoze.who config file like so:[plugin:digestauth]
use = repoze.who.plugins.digestauth:make_plugin
realm = MyRealm
get_pwdhash = mymodule:get_pwdhashThe following configuration options are available:realm:  the realm string; included verbatim in the challenge headerdomain:  the domain string; included verbatim in the challenge headerqop:  the desired quality of protection (“auth” or “auth-int”)get_password:  dotted name of a callback to get the user’s passwordget_pwdhash:  dotted name of a callback to get the user’s password hashnonce_manager:  dotted name of a class to use for nonce managementAuthenticationTo authenticate a user via Digest Auth, this plugin needs access to either
their raw password or their “password hash”, which is the MD5 digest of their
username, password and authentication realm:def calculate_pwdhash(username, password, realm):
    return md5("%s:%s:%s" % (username, realm, password)).hexdigest()You must provide the callback function “get_password” or “get_pwdhash” to
the DigestAuthPlugin.Nonce ManagementThe security of Digest Access Authentication depends crucially on the secure
generation and managent of cryptographic nonces.  In order to prevent replay
attacks the server must reject requests that have a repeated nonce.The details of nonce management have been extracted into a separate interface,
defined by the repoze.who.plugins.digestauth.noncemanager:NonceManager class.
The default implementation uses HMAC-signed tokens and an in-memory cache of
recently seen nonce counts.  If you have more particular needs you might like
to implement your own NonceManager subclass.0.1.1 - 2012-01-30Update license to MPL 2.0.
Package: repoze.who.plugins.hawkauth
This is a repoze.who plugin for Hawk Access Authentication:https://npmjs.org/package/hawkTo access resources using Hawk Access Authentication, the client must have
obtained a set of Hawk credentials including an id and secret key.  They use
these credentials to make signed requests to the server.When accessing a protected resource, the server will generate a 401 challenge
response with the scheme “Hawk” as follows:> GET /protected_resource HTTP/1.1
> Host: example.com

< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: HawkThe client will use their Hawk credentials to build a request signature and
include it in the Authorization header like so:> GET /protected_resource HTTP/1.1
> Host: example.com
> Authorization: Hawk id="h480djs93hd8",
>                     ts="1336363200",
>                     nonce="dj83hs9s",
>                     mac="bhCQXTVyfj5cmA9uKkPFx1zeOXM="

< HTTP/1.1 200 OK
< Content-Type: text/plain
<
< For your eyes only:  secret data!This plugin uses the tokenlib library for verifying Hawk credentials:https://github.com/mozilla-services/tokenlibIf this library does not meet your needs, you can provide a custom callback
function to decode the Hawk id token.0.2.0 - 2013-08-19Allow setting a custom master secret, which is passed through to tokenlib.0.1.0 - 2013-08-19Initial release.
Package: repoze.who.plugins.kerberos
IntroductionThis is a repoze.who plugin for automated authentication via Kerberos
(incl. Windows Active Directory).
You can use this plugin to authenticate your Windows Active Directory users
automatically without entering a username or password (single sign on).
In combination with repoze.who.plugins.ldap you can also use the user attributes
(fullname, email, etc.) from your Active Directory.This plugin works on Windows and linux. On linux it does not work out of the box.
You need a proper HTTP service principal in your kerberos configuration to use it.ExampleThere is a demo application to help you get started.
The configuration is in the who_activedirectory.ini file.$ hg clone https://bitbucket.org/domruf/repoze.who.plugins.kerberos
$ cd repoze.who.plugins.kerberos
$ python setup.py install
$ paster serve demo.ini
Package: repoze.who.plugins.ldap
repoze.who.plugins.ldap – LDAP Authentication for WSGI Applicationsrepoze.who.plugins.ldap is an LDAP plugin for the identification and
authentication framework for WSGI applications, repoze.who, which acts as WSGI
middleware.It provides you with an straightforward solution to enable LDAP support in your
applications. Yes, you read well: “straightforward”, “LDAP” and
“applications” are in the same sentence. In fact, you may make your application
LDAP-aware in few minutes and with few lines of code.Another great news is that this package isfullydocumented and provides you
with a working and documented demo project.See thedocssubdirectory of this package for more information, or browse
the online documentation <http://code.gustavonarea.net/repoze.who.plugins.ldap/>.repoze.who.plugins.ldap Changelog1.0 (2008-09-09)The initial release.Provided the LDAP authenticator, which is compatible with identifiers that
define the ‘login’ item in the identity dict.Included the plugin to load metadata about the authenticated user from the
LDAP server.Documented how to install and use the plugins.Included Turbogears 2 demo project, using the plugin. There is also a section
in the documentation to explain how the demo works.
Package: repoze.who.plugins.macauth
This is a repoze.who plugin for MAC Access Authentication:http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01To access resources using MAC Access Authentication, the client must have
obtained a set of MAC credentials including an id and secret key.  They use
these credentials to make signed requests to the server.When accessing a protected resource, the server will generate a 401 challenge
response with the scheme “MAC” as follows:> GET /protected_resource HTTP/1.1
> Host: example.com

< HTTP/1.1 401 Unauthorized
< WWW-Authenticate: MACThe client will use their MAC credentials to build a request signature and
include it in the Authorization header like so:> GET /protected_resource HTTP/1.1
> Host: example.com
> Authorization: MAC id="h480djs93hd8",
>                    ts="1336363200",
>                    nonce="dj83hs9s",
>                    mac="bhCQXTVyfj5cmA9uKkPFx1zeOXM="

< HTTP/1.1 200 OK
< Content-Type: text/plain
<
< For your eyes only:  secret data!This plugin uses the tokenlib library for verifying MAC credentials:https://github.com/mozilla-services/tokenlibIf this library does not meet your needs, you can provide a custom callback
function to decode the MAC id token.0.1.0 - 2012-02-27Initial release.
Package: repoze.who.plugins.memcached
This is a repoze.who IAuthenticator/IMetadataProvider plugin that can
cache the results ofotherplugins using memcached.  It’s useful for
reducing load on e.g. a backend LDAP auth system.To use it, give it the name of an authenticator and/or metadata provider
whose results it should wrap:[plugin:ldap]
use = my.ldap.authenticator

[plugin:cached_ldap]
use = repoze.who.plugins.memcached
authenticator_name = ldap

[authenticators]
plugins = cached_ldap ldap;unused(The “ldap;unused” bit ensures that the wrapped ldap plugin still gets
loaded, but is not used for matching any requests. Yeah, it’s yuck.)To prevent a compromise of the cache from revealing auth credentials, this
plugin calculates a HMAC hash of the items in the incoming identity and
uses that as the cache key.  This makes it possible to check the cache for
a match to an incoming identity, while preventing the cache keys from being
reversed back into a valid identity.Items added to the identity by the wrapped plugin will be stored in the
cached value and willnotbe encryped or obfuscated in any way.The following configuration options are available:memcached_urls:  A list of URLs for the underlying memcached store.authenticator_name:  The name of an IAuthenticator plugin to wrap.mdprovider_name:  The name of an IMetadataProvider plugin to wrap.key_items:  A list of names from the identity dict that should behashed to produce the cache key.  These items should
uniquely and validly identity a user.  By default it
will use all keys in the identity in sorted order.value_items:  A list of names from the identity dict that should bestored in the cache.  These would typically be items
of metadata such as the user’s email address.  By
default this will include all items that the wrapped
plugin adds to the identity.secret:  A string used when calculating the HMAC the cache keys.All servers accessing a shared cache should use the same
secret so they produce the same set of cache keys.ttl:  The time for which cache entries should persist, in seconds.0.1.1 - 2012-01-30Update license to MPL 2.00.1.0 - 2011-12-01Initial release.
Package: repoze.who.plugins.metadata_cache
Introductionrepoze.who.plugins.metadata_cacheis a set of plugins for therepoze.who frameworkthat enables the caching and replaying
of “one-off” user metadata, specifically targetting SSO requests.Quick start and Example ApplicationsUsage with CAS attribute releaseYou can use a metadata cache plugin withrepoze.who.plugins.casto capture the metadata
returned from ticket validation.To do this, configure a metadata cache plugin with the
samenameas theattributes_namefor the CAS plugin, and ensure you’re
using at least CAS version 2 (so setcas_version = 2.0or higher for the
CAS plugin).  During ticket validation for CAS, the attributes will be
retrieved and placed into therepoze.whoidentity for the metadata cache
plugin to pick up and hold onto.An example configuration would look like the following.  The one main thing
to make sure of is that the configuration for the attributes for the CAS
plugin matches up with thenameconfigured for themetadata_cacheplugin.  This very basic configuration stores user attributes in memory (a
Python dictionary, specifically).[plugin:casauth]use=repoze.who.plugins.cas.main_plugin:make_plugincas_url=https://cas.example.com/cas/cas_version=3.0attributes_name=attributesrememberer_name=auth_tkt[plugin:metadata_cache]use=repoze.who.plugins.metadata_cache.memory:make_pluginname=attributes...[identifiers]plugins=casauthauth_tkt[authenticators]plugins=casauthauth_tkt[challengers]plugins=casauth[mdproviders]plugins=metadata_cacheWeb server authenticationYou can use a metadata cache plugin with a front-end web server authentication
module (for example, Shibboleth) to extract user metadata out of the
environment or headers and reduce your dependency on the authentication/web
server layers above.An implementation and example for this will be coming soon.…and moreYou can also extend the classes available here for anything else where user
details come into the application via the environment or request (headers,
cookies, etc).If you build something you think is going to useful to the world at large,
send a pull request to see if it can be included.CautionBe wary of anything upstream - servers, proxies, and especially the client -
being able to spoof or inject things into the request or environment that might
inadvertently affect the given metadata being used.  A careless configuration
could compromise security.DevelopmentTo clone this project, and run the test suite, run the following:git clone git://github.com/davidjb/repoze.who.plugins.metadata_cache.git
cd repoze.who.plugins.metadata_cache
python bootstrap.py
./bin/buildout
./bin/testSend a pull request with things to fix, new features or whatever you think
could be useful.  Try to document what you’re doing and keep the code clean.
No reasonable pull request refused™.CreditsDavid Beitey (davidjb), AuthorDocumentationContentsIntroductionQuick start and Example ApplicationsUsage with CAS attribute releaseWeb server authentication…and moreCautionDevelopmentCreditsDocumentationChangesChanges0.1 (2013-04-24)Initial release.
[davidjb]
Package: repoze.who.plugins.openid
Introductionrepoze.who.plugins.openidis a plugin for therepoze.who frameworkenablingOpenIDlogins.For more information read thedocumentationor check out thesource code.Changelog0.5.3 - November 9th 2010introduce support for SReg attribute retrievalintroduce support for Attribute Exchange (AX) metadata retrievaladded webob to requirements in setup.py0.5.2 - September 25th 2009added MANIFEST.in to make egg work again0.5.1 - September 25th 2009fixed setup.py (removed doubles test suite)0.5 - March 15th 2009Initial release
Package: repoze.who.plugins.recaptcha
repoze.who.recaptchaimplements server side of the recaptcha API. ThisIAuthenticatorplugin examines environment for recaptcha form values and
requests verification.repoze.who.recaptchaworks based on form_handler condition:if form_handler parameter is not given, always perform authentication.if form_handler parameter is given, perform authentication only when one of
the form_handler values (separated by space) matches the absolute URL where the
form is processed.If the validation succeeds, no action is taken. Otherwise error is passed toenviron['repoze.who.error']andHTTPUnauthorzied(401)is triggered.Public Mercurial repo is avaliable atbitbucket.org# sample .ini configuration

[plugin:recaptcha]
use = repoze.who.plugins.captcha:make_authentication_plugin
private_key = si3di5ndlam3x44d
#optional
form_handler = /process /login /admin

[authenticators]
plugins =
        recaptchaCHANGELOG:0.1 - 21.09.2008Inital release0.2 - 23.09.2008New: optional form_handler parameter (make validation optional)New: unittestsChange: ident fixesChange: use repoze.who.logger
Package: repoze.who.plugins.saml2
SAML2 plugin for repoze.whorepoze.who.plugins.saml2is a plugin for therepoze.who
frameworkthat enables Single Sign-On
(SSO) for applications via a SAML2 identity provider (IdP).InstallationInstall from PyPipip install repoze.who.plugins.saml2Install from Githibgit clone https://github.com/akissa/repoze.who.plugins.saml2.git
cd repoze.who.plugins.saml2
python setup.py installContributingFork it (https://github.com/akissa/repoze.who.plugins.saml2/fork)Create your feature branch (git checkout-bmy-new-feature)Commit your changes (git commit-am'Add some feature')Push to the branch (git push originmy-new-feature)Create new Pull RequestLicenseAll code is licensed under theMPLv2
License.