Skip to content

Security cookbook pass #1825

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Oct 23, 2012
Merged

Security cookbook pass #1825

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
5c27ee7
remove unwanted comma
greg0ire Oct 16, 2012
7e4a506
This abbreviation felt sloppy; write like a sir
greg0ire Oct 16, 2012
6f22829
Add some punctuation here and there.
greg0ire Oct 16, 2012
128333e
Try to produce something easier to understand.
greg0ire Oct 16, 2012
c33c26a
avoid awkward awkward construction
greg0ire Oct 16, 2012
bd26b41
Add some punctuation
greg0ire Oct 16, 2012
d4f661f
It does not feel right without -ing
greg0ire Oct 16, 2012
faaac70
Improve formatting
greg0ire Oct 16, 2012
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion cookbook/security/acl_advanced.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ Object Identities
The ACL system is completely decoupled from your domain objects. They don't
even have to be stored in the same database, or on the same server. In order
to achieve this decoupling, in the ACL system your objects are represented
through object identity objects. Everytime, you want to retrieve the ACL for a
through object identity objects. Everytime you want to retrieve the ACL for a
domain object, the ACL system will first create an object identity from your
domain object, and then pass this object identity to the ACL provider for
further processing.
Expand Down
2 changes: 1 addition & 1 deletion cookbook/security/custom_authentication_provider.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -489,7 +489,7 @@ Configuration
~~~~~~~~~~~~~

You can add custom options under the ``wsse`` key in your security configuration.
For instance, the time allowed before expiring the Created header item,
For instance, the time allowed before expiring the ``Created`` header item,
by default, is 5 minutes. Make this configurable, so different firewalls
can have different timeout lengths.

Expand Down
6 changes: 3 additions & 3 deletions cookbook/security/force_https.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,9 +5,9 @@ How to force HTTPS or HTTP for Different URLs
=============================================

You can force areas of your site to use the ``HTTPS`` protocol in the security
config. This is done through the ``access_control`` rules using the ``requires_channel``
config. This is done through the ``access_control`` rules, using the ``requires_channel``
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comma is not necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what was meant here: who is using the requires_channel? The developer who writes the code (which made me add this comma), or is it the access_control rules? But maybe it does not even matter. What do you think?

If you really want me to remove this comma, how should I do this? Should I add a reverting commit to this pull request? Or make another pull request?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure, but I think that doing an stop there is odd. That's why I suggest that.
If you revert you'll lose the other change, so simple do a different PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure, but I think that doing an stop there is odd.

It feels less odd to me without the comma, so if you're not sure, I propose we let @weaverryan decide, I believe he's a native english speaker.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine! :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is actually better without the comma - it's just one straight thought, similar to I got to the hotel using a taxi.

But, the vast majority of what you had here is perfect.

Cheers!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Nomack84 : looks like you were right :) !
@weaverryan : I trust I don't have anything do to, it looks like you managed apply the PR without this commit...

option. For example, if you want to force all URLs starting with ``/secure``
to use ``HTTPS`` then you could use the following config:
to use ``HTTPS`` then you could use the following configuration:

.. configuration-block::

Expand All @@ -33,7 +33,7 @@ to use ``HTTPS`` then you could use the following config:
),
),

The login form itself needs to allow anonymous access otherwise users will
The login form itself needs to allow anonymous access, otherwise users will
be unable to authenticate. To force it to use ``HTTPS`` you can still use
``access_control`` rules by using the ``IS_AUTHENTICATED_ANONYMOUSLY``
role:
Expand Down
13 changes: 7 additions & 6 deletions cookbook/security/form_login.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,10 +105,11 @@ Redirecting after Success
You can change where the login form redirects after a successful login using
the various config options. By default the form will redirect to the URL the
user requested (i.e. the URL which triggered the login form being shown).
For example, if the user requested ``http://www.example.com/admin/post/18/edit``
then after he/she will eventually be sent back to ``http://www.example.com/admin/post/18/edit``
after successfully logging in. This is done by storing the requested URL
in the session. If no URL is present in the session (perhaps the user went
For example, if the user requested ``http://www.example.com/admin/post/18/edit``,
then after they successfully logs in, they will eventually be sent back to
``http://www.example.com/admin/post/18/edit``.
This is done by storing the requested URL in the session.
If no URL is present in the session (perhaps the user went
directly to the login page), then the user is redirected to the default page,
which is ``/`` (i.e. the homepage) by default. You can change this behavior
in several ways.
Expand Down Expand Up @@ -155,7 +156,7 @@ the following config:
),
));

Now, when no URL is set in the session users will be sent to ``/admin``.
Now, when no URL is set in the session, users will be sent to ``/admin``.

Always Redirect to the Default Page
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down Expand Up @@ -329,7 +330,7 @@ option to another value.
Redirecting on Login Failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In addition to redirect the user after a successful login, you can also set
In addition to redirecting the user after a successful login, you can also set
the URL that the user should be redirected to after a failed login (e.g. an
invalid username or password was submitted). By default, the user is redirected
back to the login form itself. You can set this to a different URL with the
Expand Down