[Python-modules-commits] [python-social-auth] 41/71: Fixes a few grammar issues in the docs
Wolfgang Borgert
debacle at moszumanska.debian.org
Sat Dec 24 15:14:27 UTC 2016
This is an automated email from the git hooks/post-receive script.
debacle pushed a commit to tag v0.2.14
in repository python-social-auth.
commit 8f615fa4216c3f4933d3613a8ca303473825be1a
Author: Kevin Harvey <kharvey at axialhealthcare.com>
Date: Fri Oct 16 10:15:28 2015 -0500
Fixes a few grammar issues in the docs
---
docs/configuration/django.rst | 9 ++++-----
docs/configuration/index.rst | 4 ++--
docs/configuration/settings.rst | 27 ++++++++++++++-------------
docs/index.rst | 2 +-
docs/logging_out.rst | 10 +++++-----
docs/pipeline.rst | 6 +++---
docs/strategies.rst | 2 +-
docs/use_cases.rst | 13 ++++++-------
8 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/docs/configuration/django.rst b/docs/configuration/django.rst
index b093434..7aeef15 100644
--- a/docs/configuration/django.rst
+++ b/docs/configuration/django.rst
@@ -38,14 +38,14 @@ Database
(For Django 1.7 and higher) sync database to create needed models::
- ./manage.py makemigrations
+ ./manage.py migrate
If you're still using South, you'll need override SOUTH_MIGRATION_MODULES_::
SOUTH_MIGRATION_MODULES = {
'default': 'social.apps.django_app.default.south_migrations'
}
-
+
Note that Django's app labels take the last part of the import, so
in this case ``social.apps.django_app.default`` becomes ``default`` here.
@@ -148,9 +148,8 @@ A base middleware is provided that handles ``SocialAuthBaseException`` by
providing a message to the user via the Django messages framework, and then
responding with a redirect to a URL defined in one of the middleware methods.
-The middleware is at ``social.apps.django_app.middleware.SocialAuthExceptionMiddleware``.
-Any method can be overrided but for simplifications these two are the
-recommended::
+The middleware is at ``social.apps.django_app.middleware.SocialAuthExceptionMiddleware``.
+Any method can be overridden, but for simplicity these two are recommended::
get_message(request, exception)
get_redirect_uri(request, exception)
diff --git a/docs/configuration/index.rst b/docs/configuration/index.rst
index 3cfa6b7..92dc283 100644
--- a/docs/configuration/index.rst
+++ b/docs/configuration/index.rst
@@ -4,8 +4,8 @@ Configuration
All the apps share the settings names, some settings for Django framework are
special (like ``AUTHENTICATION_BACKENDS``).
-Below there's a main settings document detailing the configuration and they
-purpose, plus sections detailed for each framework and they particularities.
+Below there's a main settings document detailing each configuration and its
+purpose, plus sections detailed for each framework and their particularities.
Support for more frameworks will be added in the future, pull-requests are very
welcome.
diff --git a/docs/configuration/settings.rst b/docs/configuration/settings.rst
index 0db8bb8..2824bb4 100644
--- a/docs/configuration/settings.rst
+++ b/docs/configuration/settings.rst
@@ -76,7 +76,7 @@ results and others for error situations.
``SOCIAL_AUTH_NEW_USER_REDIRECT_URL = '/new-users-redirect-url/'``
Used to redirect new registered users, will be used in place of
- ``SOCIAL_AUTH_LOGIN_REDIRECT_URL`` if defined. Note that ``?next=/foo`` is appended if present,
+ ``SOCIAL_AUTH_LOGIN_REDIRECT_URL`` if defined. Note that ``?next=/foo`` is appended if present,
if you want new users to go to next, you'll need to do it yourself.
``SOCIAL_AUTH_NEW_ASSOCIATION_REDIRECT_URL = '/new-association-redirect-url/'``
@@ -114,9 +114,9 @@ model lacks them a ``True`` value is assumed.
Tweaking some fields length
---------------------------
-Some databases impose limitations to indexes columns (like MySQL InnoDB), these
+Some databases impose limitations on index columns (like MySQL InnoDB). These
limitations won't play nice on some ``UserSocialAuth`` fields. To avoid such
-error define some of the following settings.
+errors, define some of the following settings.
``SOCIAL_AUTH_UID_LENGTH = <int>``
Used to define the max length of the field `uid`. A value of 223 should work
@@ -136,12 +136,12 @@ error define some of the following settings.
Username generation
-------------------
-Some providers return an username, others just an Id or email or first and last
+Some providers return a username, others just an ID or email or first and last
names. The application tries to build a meaningful username when possible but
defaults to generating one if needed.
-An UUID is appended to usernames in case of collisions. Here are some settings
-to control usernames generation.
+A UUID is appended to usernames in case of collisions. Here are some settings
+to control username generation.
``SOCIAL_AUTH_UUID_LENGTH = 16``
This controls the length of the UUID appended to usernames.
@@ -205,21 +205,22 @@ For OAuth backends::
Processing redirects and urlopen
--------------------------------
-The application issues several redirects and API calls, this following settings
+The application issues several redirects and API calls. The following settings
allow some tweaks to the behavior of these.
``SOCIAL_AUTH_SANITIZE_REDIRECTS = False``
The auth process finishes with a redirect, by default it's done to the
value of ``SOCIAL_AUTH_LOGIN_REDIRECT_URL`` but can be overridden with
- ``next`` GET argument. If this settings is ``True``, this application will
- very the domain of the final URL and only redirect to it if it's on the
+ ``next`` GET argument. If this setting is ``True``, this application will
+ vary the domain of the final URL and only redirect to it if it's on the
same domain.
-
+
``SOCIAL_AUTH_REDIRECT_IS_HTTPS = False``
On projects behind a reverse proxy that uses HTTPS, the redirect URIs
- can became with the wrong schema (``http://`` instead of ``https://``) when
- the request lacks some headers, and might cause errors with the auth
- process, to force HTTPS in the final URIs set this setting to ``True``
+ can have the wrong schema (``http://`` instead of ``https://``) if
+ the request lacks the appropriate headers, which might cause errors during
+ the auth process. To force HTTPS in the final URIs set this setting to
+ ``True``
``SOCIAL_AUTH_URLOPEN_TIMEOUT = 30``
Any ``urllib2.urlopen`` call will be performed with the default timeout
diff --git a/docs/index.rst b/docs/index.rst
index ca15069..473de70 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -6,7 +6,7 @@ authorization mechanism for Python projects supporting protocols like OAuth (1
and 2), OpenId and others.
The initial codebase is derived from django-social-auth_ with the idea of
-generalizing the process to suite the different frameworks around, providing
+generalizing the process to suit the different frameworks around, providing
the needed tools to bring support to new frameworks.
django-social-auth_ itself was a product of modified code from
diff --git a/docs/logging_out.rst b/docs/logging_out.rst
index aed9ed6..bd10bd8 100644
--- a/docs/logging_out.rst
+++ b/docs/logging_out.rst
@@ -1,13 +1,13 @@
Disconnect and Logging Out
==========================
-It's a common misconception that ``disconnect`` action is the same as logging
-the user out, but is far from it.
+It's a common misconception that the ``disconnect`` action is the same as
+logging the user out, but this is not the case.
-``Disconnect`` is the way that your users have to say to you "forget about my
-account", that implies removing the ``UserSocialAuth`` instance that was
+``Disconnect`` is the way that your users can ask your project to "forget about
+my account". This implies removing the ``UserSocialAuth`` instance that was
created, this also implies that the user won't be able to login back into your
-site with the social account, instead the action will be a signup, a new user
+site with the social account. Instead the action will be a signup, a new user
instance will be created, not related to the previous one.
Logging out is just a way to say "forget my current session", and usually
diff --git a/docs/pipeline.rst b/docs/pipeline.rst
index b22987a..715abf4 100644
--- a/docs/pipeline.rst
+++ b/docs/pipeline.rst
@@ -75,8 +75,8 @@ The default pipeline is composed by::
)
-It's possible to override it by defining the setting ``SOCIAL_AUTH_PIPELINE``,
-for example a pipeline that won't create users, just accept already registered
+It's possible to override it by defining the setting ``SOCIAL_AUTH_PIPELINE``.
+For example, a pipeline that won't create users, just accept already registered
ones would look like this::
SOCIAL_AUTH_PIPELINE = (
@@ -178,7 +178,7 @@ There's a pipeline to validate email addresses, but it relies a lot on your
project.
The pipeline is at ``social.pipeline.mail.mail_validation`` and it's a partial
-pipeline, it will return a redirect to an URL that you can use to tell the
+pipeline, it will return a redirect to a URL that you can use to tell the
users that an email validation was sent to them. If you want to mention the
email address you can get it from the session under the key ``email_validation_address``.
diff --git a/docs/strategies.rst b/docs/strategies.rst
index 0a2086f..72e014e 100644
--- a/docs/strategies.rst
+++ b/docs/strategies.rst
@@ -8,7 +8,7 @@ capabilities under a common API to reuse as much code as possible.
Description
-----------
-An strategy responsibility is to provide access to:
+A strategy's responsibility is to provide access to:
* Request data and host information and URI building
* Session access
diff --git a/docs/use_cases.rst b/docs/use_cases.rst
index bebb60a..3ac5856 100644
--- a/docs/use_cases.rst
+++ b/docs/use_cases.rst
@@ -7,13 +7,12 @@ Some miscellaneous options and use cases for python-social-auth_.
Return the user to the original page
------------------------------------
-There's a common scenario where it's desired to return the user back to the
-original page from where it was requested to login. For that purpose, the usual
-``next`` query-string argument is used, the value of this parameter will be
-stored in the session and later used to redirect the user when login was
-successful.
+There's a common scenario to return the user back to the original page from
+where they requested to login. For that purpose, the usual ``next`` query-string
+argument is used. The value of this parameter will be stored in the session and
+later used to redirect the user when login was successful.
-In order to use it just define it with your link, for instance, when using
+In order to use it, just define it with your link. For instance, when using
Django::
<a href="{% url 'social:begin' 'facebook' %}?next={{ request.path }}">Login with Facebook</a>
@@ -155,7 +154,7 @@ At the moment python-social-auth_ doesn't provide a method to define multiple
scopes for single backend, this is usually desired since it's recommended to
ask the user for the minimum scope possible and increase the access when it's
really needed. It's possible to add a new backend extending the original one to
-accomplish that behavior, there are two ways to do it.
+accomplish that behavior. There are two ways to do it.
1. Overriding ``get_scope()`` method::
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/python-modules/packages/python-social-auth.git
More information about the Python-modules-commits
mailing list