Fix some typos and formatting.
Fix the note markup. It was extending over all the rest of the page.
This commit is contained in:
parent
e7ad2da34a
commit
dffc13fef2
9 changed files with 34 additions and 20 deletions
|
@ -11,10 +11,10 @@ we will do to this extent.
|
|||
|
||||
Fedora Infrastructure is a community team, involving volunteers as well as
|
||||
people employed by Red Hat to work on Fedora.
|
||||
However, despite the help of volunteers primary business hours are mostly
|
||||
aligned with the workk schedule of Red Hat. Normal hours should be seen as
|
||||
during Mondayy through Friday 1400 UTC to 2300 UTC with US national holidays and
|
||||
a 2 weeks end of year closure affecting staffing and response times.
|
||||
However, despite the help of volunteers, primary business hours are mostly
|
||||
aligned with the work schedule of Red Hat. Normal hours should be seen as
|
||||
Monday through Friday from 1400 UTC to 2300 UTC, excluding US national holidays
|
||||
and a 2 weeks end of year closure affecting staffing and response times.
|
||||
|
||||
Services outside of primary business hours are done on call and depend on
|
||||
the availability of staff.
|
||||
|
@ -82,7 +82,7 @@ items rely on services in their own circle or a circle below them.
|
|||
. *Deprecated* services are ones which Fedora Infrastructure are no longer
|
||||
putting resources into. This may be because the project has completed its
|
||||
mission, the upstream software is dead, or the original reasons for the
|
||||
product are available. Problems with these services will be looked at
|
||||
service no longer exists. Problems with these services will be looked at
|
||||
during primary business hours. Responses may be mostly "Will Not Fix".
|
||||
|
||||
== Limitations on Support
|
||||
|
|
|
@ -21,7 +21,9 @@ All new applications should use OpenID Connect for user authentication.
|
|||
====
|
||||
Many existing applications use OpenID 2.0 and should eventually migrate
|
||||
to OpenID Connect.
|
||||
====OpenID Connect is an authentication layer built on top of OAuth 2.0
|
||||
====
|
||||
|
||||
OpenID Connect is an authentication layer built on top of OAuth 2.0
|
||||
so to understand OpenID Connect you should first be familiar with OAuth
|
||||
2.0 and its various flows prior to learning about OpenID Connect.
|
||||
|
||||
|
@ -42,7 +44,9 @@ https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest[requires
|
|||
that the "openid" scope is requested]. Failing to do so will result in
|
||||
undefined behavior. In the case of Ipsilon, you won't have access to the
|
||||
UserInfo or recieve an ID token.
|
||||
======= Libraries
|
||||
====
|
||||
|
||||
=== Libraries
|
||||
|
||||
==== OAuthLib
|
||||
|
||||
|
|
|
@ -20,7 +20,9 @@ correctly styled before merging pull requests.
|
|||
There are a few PEP8 rules which will vary from project to project. For
|
||||
example, the maximum line length might vary. The test suite should
|
||||
enforce this.
|
||||
======== Enforcement
|
||||
====
|
||||
|
||||
==== Enforcement
|
||||
|
||||
Projects should automatically enforce code style. How a project does so
|
||||
is up to the maintainers, but several good options are documented here.
|
||||
|
|
|
@ -24,7 +24,9 @@ Python documentation into HTML pages.
|
|||
Improving documentation is a great way to get involved in a project.
|
||||
When adding new documentation or cleaning up existing documentation,
|
||||
please follow the guidelines below.
|
||||
======= Style
|
||||
====
|
||||
|
||||
=== Style
|
||||
|
||||
Sphinx supports three different documentation styles. By default, Sphinx
|
||||
expects ReStructuredText. However, it has included an extension to
|
||||
|
|
|
@ -11,7 +11,9 @@ they're interested in receiving.
|
|||
fedmsg does not guarantee message delivery. Messages will be lost and
|
||||
your application should never depend on the reliable delivery of fedmsgs
|
||||
to function.
|
||||
======= Topics
|
||||
====
|
||||
|
||||
=== Topics
|
||||
|
||||
==== Existing Topics
|
||||
|
||||
|
|
|
@ -21,7 +21,9 @@ For historical reasons, you may find applications that don't use Flask.
|
|||
Other frameworks currently in use include
|
||||
https://www.djangoproject.com/[Django] and
|
||||
http://docs.pylonsproject.org/projects/pyramid/en/latest/[Pyramid].
|
||||
====Flask is designed to be extensible, so it's common to use extensions
|
||||
====
|
||||
|
||||
Flask is designed to be extensible, so it's common to use extensions
|
||||
with the core flask library. A few common extensions are documented
|
||||
below.
|
||||
|
||||
|
|
|
@ -48,7 +48,7 @@ bindings.
|
|||
The message broker can use https://www.rabbitmq.com/vhosts.html[virtual
|
||||
hosts] to allow multiple applications to use the broker. The general
|
||||
purpose publish-subscribe virtual host is called `/pubsub` and has its
|
||||
authorization policy is outlined below. If your application is using a
|
||||
authorization policy outlined below. If your application is using a
|
||||
different virtual host for private messaging (for example, your
|
||||
application uses Celery), different authorization rules apply.
|
||||
|
||||
|
@ -67,7 +67,9 @@ Because AMQP clients don't have permission to create objects, you need
|
|||
to set
|
||||
https://fedora-messaging.readthedocs.io/en/stable/configuration.html#passive-declares[passive_declares
|
||||
= true] or you will get 403 Permission Denied errors.
|
||||
====Users, exchanges, queues, bindings, and
|
||||
====
|
||||
|
||||
Users, exchanges, queues, bindings, and
|
||||
https://www.rabbitmq.com/vhosts.html[virtual hosts] other objects are
|
||||
managed in the broker using the Fedora Infrastructure Ansible project
|
||||
and must be declared there.
|
||||
|
|
|
@ -69,7 +69,7 @@ call MUST be protected against cross-site request forgery.
|
|||
|
||||
The application MUST set the Secure flag on any cookies it sets if it is
|
||||
not in a development mode. The application MUST set the httpOnly flag on
|
||||
any cookiees it sets. The application SHOULD NOT set a Domain parameter
|
||||
any cookies it sets. The application SHOULD NOT set a Domain parameter
|
||||
in any cookies it sets, if it does set the Domain, its value MUST be
|
||||
identical to the exact Host requested.
|
||||
|
||||
|
@ -81,16 +81,16 @@ inserted into a frame. Setting anything else than `DENY` is a flag for
|
|||
review. The application MUST set the `X-Xss-Protection` header, and the
|
||||
value MUST be `1; mode=block`. The application MUST set the
|
||||
`X-Content-Type-Options` header, and the value MUST be `nosniff`. The
|
||||
application MUST set the `\`Referrer-Policy`[.title-ref]##_ header, and
|
||||
application MUST set the `Referrer-Policy`[.title-ref]## header, and
|
||||
the value MUST be ##[.title-ref]##no-referrer##[.title-ref]## or
|
||||
##[.title-ref]##same-origin##`.
|
||||
##[.title-ref]##same-origin##.
|
||||
|
||||
The application MUST set the `\`Content-Security-Policy`[.title-ref]##_
|
||||
The application MUST set the `Content-Security-Policy`[.title-ref]##
|
||||
header and MUST set at least
|
||||
##[.title-ref]##default-src##[.title-ref]##. The content security MUST
|
||||
NOT allow any origins other than ##[.title-ref]##'none'##[.title-ref]##,
|
||||
##[.title-ref]##'self'##[.title-ref]##, any of the explicitly approved
|
||||
origins (listed below) or ##[.title-ref]##nonce-$nonce##`. Any nonces
|
||||
origins (listed below) or ##[.title-ref]##nonce-$nonce##. Any nonces
|
||||
used for the content security policy MUST be generated via a
|
||||
Cryptographically Secure PRNG.
|
||||
|
||||
|
|
|
@ -74,7 +74,7 @@ Specification]
|
|||
|
||||
The format is somewhat simple if you remember a few key points:
|
||||
|
||||
* Sections are deliniated by underlined texts. The convention is:
|
||||
* Sections are delineated by underlined texts. The convention is:
|
||||
** Title has "=" above and below the title text, at least as many
|
||||
columns as the title itself.
|
||||
** Top level sections are underlined by "===" - at least as many columns
|
||||
|
@ -82,7 +82,7 @@ as the section title in the line above.
|
|||
** Second level sections are underlined by "---"
|
||||
** Any of
|
||||
`! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ \` { | } ~` are
|
||||
valid section deliniators. If you need more than two section levels,
|
||||
valid section delineators. If you need more than two section levels,
|
||||
choose between them but be sure to be consistent.
|
||||
* Indents are significant. Only indent for things like block quotes,
|
||||
nested lists etc. Match the tabstop of the document you are editing.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue