updating content files
This commit is contained in:
Grace Park
@@ -11,13 +11,13 @@ redirect_from:
|
||||
---
|
||||
If you follow these best practices it will help you to provide a good customer experience.
|
||||
|
||||
### Customer communication
|
||||
## Customer communication
|
||||
|
||||
- Marketing materials for the app should accurately represent the app's behavior.
|
||||
- Apps should include links to user-facing documentation that describe how to set up and use the app.
|
||||
- Customers should be able to see what type of plan they have in the billing, profile, or account settings section of the app.
|
||||
- Customers should be able to install and use your app on both a personal account and an organization account. They should be able to view and manage the app on those accounts separately.
|
||||
|
||||
### Plan management
|
||||
## Plan management
|
||||
|
||||
{% data reusables.marketplace.marketplace-billing-ui-requirements %}
|
||||
|
||||
@@ -18,11 +18,11 @@ topics:
|
||||
|
||||
The requirements for listing an app on {% data variables.product.prodname_marketplace %} vary according to whether you want to offer a free or a paid app.
|
||||
|
||||
### Requirements for all {% data variables.product.prodname_marketplace %} listings
|
||||
## Requirements for all {% data variables.product.prodname_marketplace %} listings
|
||||
|
||||
All listings on {% data variables.product.prodname_marketplace %} should be for tools that provide value to the {% data variables.product.product_name %} community. When you submit your listing for publication, you must read and accept the terms of the "[{% data variables.product.prodname_marketplace %} Developer Agreement](/articles/github-marketplace-developer-agreement/)."
|
||||
|
||||
#### User experience requirements for all apps
|
||||
### User experience requirements for all apps
|
||||
|
||||
All listings should meet the following requirements, regardless of whether they are for a free or paid app.
|
||||
|
||||
@@ -36,7 +36,7 @@ All listings should meet the following requirements, regardless of whether they
|
||||
|
||||
For more information on providing a good customer experience, see "[Customer experience best practices for apps](/developers/github-marketplace/customer-experience-best-practices-for-apps)."
|
||||
|
||||
#### Brand and listing requirements for all apps
|
||||
### Brand and listing requirements for all apps
|
||||
|
||||
- Apps that use GitHub logos must follow the {% data variables.product.company_short %} guidelines. For more information, see "[{% data variables.product.company_short %} Logos and Usage](https://github.com/logos)."
|
||||
- Apps must have a logo, feature card, and screenshots images that meet the recommendations provided in "[Writing {% data variables.product.prodname_marketplace %} listing descriptions](/marketplace/listing-on-github-marketplace/writing-github-marketplace-listing-descriptions/)."
|
||||
@@ -44,11 +44,11 @@ For more information on providing a good customer experience, see "[Customer exp
|
||||
|
||||
To protect your customers, we recommend that you also follow security best practices. For more information, see "[Security best practices for apps](/developers/github-marketplace/security-best-practices-for-apps)."
|
||||
|
||||
### Considerations for free apps
|
||||
## Considerations for free apps
|
||||
|
||||
{% data reusables.marketplace.free-apps-encouraged %}
|
||||
|
||||
### Requirements for paid apps
|
||||
## Requirements for paid apps
|
||||
|
||||
To publish a paid plan for your app on {% data variables.product.prodname_marketplace %}, your app must be owned by an organization that is a verified publisher. For more information about the verification process or transferring ownership of your app, see "[Applying for publisher verification for your organization](/developers/github-marketplace/applying-for-publisher-verification-for-your-organization)."
|
||||
|
||||
@@ -68,7 +68,7 @@ When you are ready to publish the app on {% data variables.product.prodname_mark
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Billing requirements for paid apps
|
||||
## Billing requirements for paid apps
|
||||
|
||||
Your app does not need to handle payments but does need to use {% data variables.product.prodname_marketplace %} purchase events to manage new purchases, upgrades, downgrades, cancellations, and free trials. For information about how integrate these events into your app, see "[Using the {% data variables.product.prodname_marketplace %} API in your app](/developers/github-marketplace/using-the-github-marketplace-api-in-your-app)."
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ topics:
|
||||
---
|
||||
If you follow these best practices it will help you to provide a secure user experience.
|
||||
|
||||
### Authorization, authentication, and access control
|
||||
## Authorization, authentication, and access control
|
||||
|
||||
We recommend creating a GitHub App rather than an OAuth App. {% data reusables.marketplace.github_apps_preferred %}. See "[Differences between GitHub Apps and OAuth Apps](/apps/differences-between-apps/)" for more details.
|
||||
- Apps should use the principle of least privilege and should only request the OAuth scopes and GitHub App permissions that the app needs to perform its intended functionality. For more information, see [Principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) in Wikipedia.
|
||||
@@ -28,7 +28,7 @@ We recommend creating a GitHub App rather than an OAuth App. {% data reusables.m
|
||||
- OAuth Apps should authenticate using an [OAuth token](/apps/building-oauth-apps/authorizing-oauth-apps/).
|
||||
- GitHub Apps should authenticate using either a [JSON Web Token (JWT)](/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-a-github-app), [OAuth token](/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/), or [installation access token](/apps/building-github-apps/authenticating-with-github-apps/#authenticating-as-an-installation).
|
||||
|
||||
### Data protection
|
||||
## Data protection
|
||||
|
||||
- Apps should encrypt data transferred over the public internet using HTTPS, with a valid TLS certificate, or SSH for Git.
|
||||
- Apps should store client ID and client secret keys securely. We recommend storing them as [environmental variables](http://en.wikipedia.org/wiki/Environment_variable#Getting_and_setting_environment_variables).
|
||||
@@ -36,7 +36,7 @@ We recommend creating a GitHub App rather than an OAuth App. {% data reusables.m
|
||||
- Apps should not require the user to provide their GitHub password.
|
||||
- Apps should encrypt tokens, client IDs, and client secrets.
|
||||
|
||||
### Logging and monitoring
|
||||
## Logging and monitoring
|
||||
|
||||
Apps should have logging and monitoring capabilities. App logs should be retained for at least 30 days and archived for at least one year.
|
||||
A security log should include:
|
||||
@@ -49,13 +49,13 @@ A security log should include:
|
||||
- Consistent timestamping for each event
|
||||
- Source users, IP addresses, and/or hostnames for all logged actions
|
||||
|
||||
### Incident response workflow
|
||||
## Incident response workflow
|
||||
|
||||
To provide a secure experience for users, you should have a clear incident response plan in place before listing your app. We recommend having a security and operations incident response team in your company rather than using a third-party vendor. You should have the capability to notify {% data variables.product.product_name %} within 24 hours of a confirmed incident.
|
||||
|
||||
For an example of an incident response workflow, see the "Data Breach Response Policy" on the [SANS Institute website](https://www.sans.org/information-security-policy/). A short document with clear steps to take in the event of an incident is more valuable than a lengthy policy template.
|
||||
|
||||
### Vulnerability management and patching workflow
|
||||
## Vulnerability management and patching workflow
|
||||
|
||||
You should conduct regular vulnerability scans of production infrastructure. You should triage the results of vulnerability scans and define a period of time in which you agree to remediate the vulnerability.
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ You can view metrics for the past day (24 hours), week, month, or for the entire
|
||||
|
||||
{% endnote %}
|
||||
|
||||
### Performance metrics
|
||||
## Performance metrics
|
||||
|
||||
The Insights page displays these performance metrics, for the selected time period:
|
||||
|
||||
@@ -34,7 +34,7 @@ The Insights page displays these performance metrics, for the selected time peri
|
||||
|
||||
{% endnote %}
|
||||
|
||||
#### Conversion performance
|
||||
### Conversion performance
|
||||
|
||||
* **Unique visitors to landing page:** Number of people who viewed your GitHub App's landing page.
|
||||
* **Unique visitors to checkout page:** Number of people who viewed one of your GitHub App's checkout pages.
|
||||
|
||||
@@ -18,7 +18,7 @@ topics:
|
||||
|
||||
You can view or download the transaction data to keep track of your subscription activity. Click the **Export CSV** button to download a `.csv` file. You can also select a period of time to view and search within the transaction page.
|
||||
|
||||
### Transaction data fields
|
||||
## Transaction data fields
|
||||
|
||||
* **date:** The date of the transaction in `yyyy-mm-dd` format.
|
||||
* **app_name:** The app name.
|
||||
@@ -32,7 +32,7 @@ You can view or download the transaction data to keep track of your subscription
|
||||
|
||||
|
||||
|
||||
### Accessing {% data variables.product.prodname_marketplace %} transactions
|
||||
## Accessing {% data variables.product.prodname_marketplace %} transactions
|
||||
|
||||
To access {% data variables.product.prodname_marketplace %} transactions:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user