Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: ory/fosite
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v0.27.0
Choose a base ref
...
head repository: ory/fosite
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: master
Choose a head ref

Commits on Nov 3, 2018

  1. oauth2: Improve refresh security and reliability (#332)

    This patch resolves several issues regarding the refresh flow. First,
    an issue has been resolved which caused the audience to not be
    set in the refreshed access tokens.
    
    Second, scope and audience are validated against the client's
    whitelisted values and if the values are no longer allowed,
    the grant is canceled.
    
    Closes #331
    Closes #325
    Closes #324
    aeneasr authored Nov 3, 2018
    Copy the full SHA
    4e4121b View commit details

Commits on Nov 7, 2018

  1. pkce: Allow hybrid flows (#328)

    Signed-off-by: Adam Shannon <adamkshannon@gmail.com>
    Signed-off-by: Wenhao Ni <niwenhao@gmail.com>
    niwenhao authored and aeneasr committed Nov 7, 2018
    Copy the full SHA
    cdfddc8 View commit details

Commits on Nov 8, 2018

  1. oauth2: Set exp for authorize code issued by hybrid flow (#333)

    Signed-off-by: nerocrux <nerocrux@gmail.com>
    nerocrux authored and aeneasr committed Nov 8, 2018
    Copy the full SHA
    d275e84 View commit details

Commits on Nov 12, 2018

  1. introspect: Omit exp if ExpiresAt is zero value (#334)

    Signed-off-by: nerocrux <nerocrux@gmail.com>
    nerocrux authored and aeneasr committed Nov 12, 2018
    Copy the full SHA
    6d50176 View commit details
  2. docs: Fix quickstart (#335)

    - replace NewMemoryStore with NewExampleStore
    - fix length of signing key
    - fix config type
    
    Signed-off-by: Peter Schultz <peter.schultz@classmarkets.com>
    pschultz authored and aeneasr committed Nov 12, 2018
    Copy the full SHA
    25cc6c4 View commit details

Commits on Nov 16, 2018

  1. oauth2: Add ability to specify refresh token lifespan (#337)

    Set it to `-1` to disable this feature. Defaults to 30 days.
    
    Closes #319
    
    Signed-off-by: arekkas <aeneas@ory.am>
    aeneasr authored Nov 16, 2018
    Copy the full SHA
    fa65408 View commit details

Commits on Nov 29, 2018

  1. Remove cryptopasta dependency (#339)

    Signed-off-by: nerocrux <nerocrux@gmail.com>
    nerocrux authored and aeneasr committed Nov 29, 2018
    Copy the full SHA
    b156e6b View commit details

Commits on Dec 4, 2018

  1. compose: Expose token entropy setting (#342)

    Signed-off-by: nerocrux <nerocrux@gmail.com>
    nerocrux authored and aeneasr committed Dec 4, 2018
    Copy the full SHA
    0761fca View commit details

Commits on Dec 23, 2018

  1. oauth2: Don't double encode URL fragments (#346)

    Closes #345
    
    Signed-off-by: Grigoriev, Nikolai <nikolai.grigoriev@nuance.com>
    ngrigoriev authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    1f41934 View commit details
  2. storage: adds new interface Transactional which is to be implemente…

    …d by storage providers that can support transactions.
    
    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    c364b33 View commit details
  3. oauth2: use transactions in the refresh token flow (if the storage im…

    …plementation implements the `Transactional` interface) to address #309
    
    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    07d1a39 View commit details
  4. internal: add mock for storage.Transactional + update generate-mocks.sh

    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    03f7bc8 View commit details
  5. oauth2: add test coverage to exercise the transactional support in th…

    …e RefreshTokenGrantHandler's PopulateTokenEndpointResponse method.
    
    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    b38d7c8 View commit details
  6. oauth2: use transactions in the auth code token flow (if the storage …

    …implementation implements the `Transactional` interface) to address #309
    
    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    e00c567 View commit details
  7. oauth2: add test coverage to exercise the transactional support in th…

    …e AuthorizeExplicitGrantHandler's PopulateTokenEndpointResponse method.
    
    Signed-off-by: Amir Aslaminejad <aslaminejad@gmail.com>
    aaslamin authored and aeneasr committed Dec 23, 2018
    Copy the full SHA
    2f58f9e View commit details

Commits on Feb 7, 2019

  1. doc: Update HISTORY.md, README.md, CONTRIBUTING.md (#347)

    * README: Breaks out `0.26.0` as was stuck inside a code block.
    * README: Ensures the later versions formats code blocks as Go code.
    * Runs doctoc to ensure TOCs are up to date.
    
    Signed-off-by: Matthew Hartstonge <matt@mykro.co.nz>
    matthewhartstonge authored and aeneasr committed Feb 7, 2019
    Copy the full SHA
    de5e61e View commit details

Commits on Feb 18, 2019

  1. errors: Remove useless details fn receiver (#349)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Feb 18, 2019
    Copy the full SHA
    af403c6 View commit details

Commits on Mar 18, 2019

  1. example: Propagate session data properly (#353)

    This example is slightly inaccurate; the session data will need to come from the returned AccessRequester, not the pre-created session. The session passed to IntrospectToken isn't mutated.
    
    Signed-off-by: David Ashby <delta.mu.alpha@gmail.com>
    deltamualpha authored and aeneasr committed Mar 18, 2019
    Copy the full SHA
    5ba0f04 View commit details

Commits on Mar 27, 2019

  1. token: Improve rotated secret error reporting in HMAC strategy (#354)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Mar 27, 2019
    Copy the full SHA
    f21d930 View commit details

Commits on Apr 11, 2019

  1. Allow providing a custom redirect URI checker (#355)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Apr 11, 2019
    Copy the full SHA
    3d16e39 View commit details

Commits on Apr 17, 2019

  1. Improve IsRedirectURISecure check

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr committed Apr 17, 2019
    Copy the full SHA
    d6f8962 View commit details
  2. Export IsLocalhost

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr committed Apr 17, 2019
    Copy the full SHA
    a95ea09 View commit details

Commits on Apr 25, 2019

  1. core: Add debug log to invalid_client error(#358)

    Signed-off-by: nerocrux <nerocrux@gmail.com>
    nerocrux authored and aeneasr committed Apr 25, 2019
    Copy the full SHA
    dce3111 View commit details

Commits on Apr 26, 2019

  1. openid: Allow promp=none for https/localhost (#359)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Apr 26, 2019
    Copy the full SHA
    27bbe00 View commit details

Commits on May 15, 2019

  1. docs: Updates issue and pull request templates (#361)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored May 15, 2019
    Copy the full SHA
    35157e2 View commit details

Commits on May 21, 2019

  1. docs: Fix method/struct documents (#360)

    Signed-off-by: budougumi0617 <budougumi0617@gmail.com>
    budougumi0617 authored and aeneasr committed May 21, 2019
    Copy the full SHA
    ad06f22 View commit details

Commits on May 23, 2019

  1. docs: Updates issue and pull request templates (#365)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored May 23, 2019
    Copy the full SHA
    90a3c50 View commit details
  2. docs: Updates issue and pull request templates (#366)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored May 23, 2019
    Copy the full SHA
    27c64ec View commit details
  3. docs: Updates issue and pull request templates (#367)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored May 23, 2019
    Copy the full SHA
    01cd955 View commit details

Commits on Jul 2, 2019

  1. Create FUNDING.yml

    aeneasr authored Jul 2, 2019
    Copy the full SHA
    1b7b479 View commit details

Commits on Jul 23, 2019

  1. docs: Updates issue and pull request templates (#373)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Jul 23, 2019
    Copy the full SHA
    5962474 View commit details

Commits on Aug 5, 2019

  1. docs: Updates issue and pull request templates (#374)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Aug 5, 2019
    Copy the full SHA
    9f7cf40 View commit details

Commits on Aug 6, 2019

  1. Copy the full SHA
    7219387 View commit details

Commits on Aug 9, 2019

  1. docs: Updates issue and pull request templates (#376)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Aug 9, 2019
    Copy the full SHA
    165e93e View commit details
  2. docs: Updates issue and pull request templates (#377)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Aug 9, 2019
    Copy the full SHA
    40590cb View commit details

Commits on Aug 11, 2019

  1. docs: Updates issue and pull request templates (#378)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Aug 11, 2019
    Copy the full SHA
    54426bb View commit details

Commits on Aug 29, 2019

  1. handler/revoke: respecting ErrInvalidRequest code (#380)

    This commit modifies the case for ErrInvalidRequest in
    WriteRevocationResponse to respect the 400 error code
    and not fallthrough to ErrInvalidClient.
    
    Author:    DefinitelyNotAGoat <baldrich@protonmail.com>
    DefinitelyNotAGoat authored and aeneasr committed Aug 29, 2019
    Copy the full SHA
    cc34bfb View commit details

Commits on Sep 16, 2019

  1. Add RefreshTokenScopes Config (#371)

    When set to true, this will return refresh tokens even if the user did
    not ask for the offline or offline_access Oauth Scope.
    dmcinnes authored and aeneasr committed Sep 16, 2019
    Copy the full SHA
    bcc7859 View commit details
  2. Copy the full SHA
    e21830e View commit details

Commits on Sep 23, 2019

  1. Copy the full SHA
    024667a View commit details

Commits on Oct 28, 2019

  1. Copy the full SHA
    40a49f7 View commit details

Commits on Nov 21, 2019

  1. Copy the full SHA
    3ece795 View commit details

Commits on Jan 20, 2020

  1. docs: Updates issue and pull request templates (#393)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Jan 20, 2020
    Copy the full SHA
    cdefb3e View commit details

Commits on Feb 2, 2020

  1. docs: Updates issue and pull request templates (#394)

    Signed-off-by: aeneasr <aeneas@ory.sh>
    aeneasr authored Feb 2, 2020
    Copy the full SHA
    119e6ab View commit details

Commits on Feb 20, 2020

  1. Copy the full SHA
    387cade View commit details

Commits on Mar 2, 2020

  1. fix: Merge request ID as well (#398)

    Closes #386
    aeneasr authored Mar 2, 2020
    Copy the full SHA
    67c081c View commit details

Commits on Mar 3, 2020

  1. feat: Add ExactOne and MatchesExact to Arguments (#399)

    Previously Arguments.Exact had vague semantic where
    it coudln't distinguish between value with a space and multiple
    values. Split it into 2 functions with clear semantic.
    
    Old .Exact() remains for compatibility and marked as deprecated
    redbaron authored Mar 3, 2020
    Copy the full SHA
    cf23400 View commit details

Commits on Mar 4, 2020

  1. Copy the full SHA
    4104135 View commit details

Commits on Mar 17, 2020

  1. Copy the full SHA
    f99bb80 View commit details

Commits on Mar 25, 2020

  1. fix: handle concurrent transactional errors in the refresh token gran…

    …t handler (#402)
    
    This commit provides the functionality required to address ory/hydra#1719 & ory/hydra#1735 by adding error checking to the RefreshTokenGrantHandler's PopulateTokenEndpointResponse method so it can deal with errors due to concurrent access. This will allow the authorization server to render a better error to the user-agent.
    
    No longer returns fosite.ErrServerError in the event the storage. Instead a wrapped fosite.ErrNotFound is returned when fetching the refresh token fails due to it no longer being present. This scenario is caused when the user sends two or more request to refresh using the same token and one request gets into the handler just after the prior request finished and successfully committed its transaction.
    
    Adds unit test coverage for transaction error handling logic added to the RefreshTokenGrantHandler's PopulateTokenEndpointResponse method
    aaslamin authored Mar 25, 2020
    Copy the full SHA
    b17190b View commit details
Showing 311 changed files with 31,932 additions and 7,885 deletions.
1 change: 1 addition & 0 deletions .github/CODEOWNERS
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
* @aeneasr @ory/product-development
8 changes: 8 additions & 0 deletions .github/FUNDING.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# AUTO-GENERATED, DO NOT EDIT!
# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/FUNDING.yml

# These are supported funding model platforms

# github:
patreon: _ory
open_collective: ory
122 changes: 122 additions & 0 deletions .github/ISSUE_TEMPLATE/BUG-REPORT.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,122 @@
# AUTO-GENERATED, DO NOT EDIT!
# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/BUG-REPORT.yml

description: "Create a bug report"
labels:
- bug
name: "Bug Report"
body:
- attributes:
value: "Thank you for taking the time to fill out this bug report!\n"
type: markdown
- attributes:
label: "Preflight checklist"
options:
- label:
"I could not find a solution in the existing issues, docs, nor
discussions."
required: true
- label:
"I agree to follow this project's [Code of
Conduct](https://github.com/ory/fosite/blob/master/CODE_OF_CONDUCT.md)."
required: true
- label:
"I have read and am following this repository's [Contribution
Guidelines](https://github.com/ory/fosite/blob/master/CONTRIBUTING.md)."
required: true
- label:
"I have joined the [Ory Community Slack](https://slack.ory.sh)."
- label:
"I am signed up to the [Ory Security Patch
Newsletter](https://www.ory.sh/l/sign-up-newsletter)."
id: checklist
type: checkboxes
- attributes:
description:
"Enter the slug or API URL of the affected Ory Network project. Leave
empty when you are self-hosting."
label: "Ory Network Project"
placeholder: "https://<your-project-slug>.projects.oryapis.com"
id: ory-network-project
type: input
- attributes:
description: "A clear and concise description of what the bug is."
label: "Describe the bug"
placeholder: "Tell us what you see!"
id: describe-bug
type: textarea
validations:
required: true
- attributes:
description: |
Clear, formatted, and easy to follow steps to reproduce the behavior:
placeholder: |
Steps to reproduce the behavior:
1. Run `docker run ....`
2. Make API Request to with `curl ...`
3. Request fails with response: `{"some": "error"}`
label: "Reproducing the bug"
id: reproduce-bug
type: textarea
validations:
required: true
- attributes:
description:
"Please copy and paste any relevant log output. This will be
automatically formatted into code, so no need for backticks. Please
redact any sensitive information"
label: "Relevant log output"
render: shell
placeholder: |
log=error ....
id: logs
type: textarea
- attributes:
description:
"Please copy and paste any relevant configuration. This will be
automatically formatted into code, so no need for backticks. Please
redact any sensitive information!"
label: "Relevant configuration"
render: yml
placeholder: |
server:
admin:
port: 1234
id: config
type: textarea
- attributes:
description: "What version of our software are you running?"
label: Version
id: version
type: input
validations:
required: true
- attributes:
label: "On which operating system are you observing this issue?"
options:
- Ory Network
- macOS
- Linux
- Windows
- FreeBSD
- Other
id: operating-system
type: dropdown
- attributes:
label: "In which environment are you deploying?"
options:
- Ory Network
- Docker
- "Docker Compose"
- "Kubernetes with Helm"
- Kubernetes
- Binary
- Other
id: deployment
type: dropdown
- attributes:
description: "Add any other context about the problem here."
label: Additional Context
id: additional
type: textarea
125 changes: 125 additions & 0 deletions .github/ISSUE_TEMPLATE/DESIGN-DOC.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,125 @@
# AUTO-GENERATED, DO NOT EDIT!
# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/DESIGN-DOC.yml

description:
"A design document is needed for non-trivial changes to the code base."
labels:
- rfc
name: "Design Document"
body:
- attributes:
value: |
Thank you for writing this design document.
One of the key elements of Ory's software engineering culture is the use of defining software designs through design docs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions.
Ory is leaning heavily on [Google's design docs process](https://www.industrialempathy.com/posts/design-docs-at-google/)
and [Golang Proposals](https://github.com/golang/proposal).
Writing a design doc before contributing your change ensures that your ideas are checked with
the community and maintainers. It will save you a lot of time developing things that might need to be changed
after code reviews, and your pull requests will be merged faster.
type: markdown
- attributes:
label: "Preflight checklist"
options:
- label:
"I could not find a solution in the existing issues, docs, nor
discussions."
required: true
- label:
"I agree to follow this project's [Code of
Conduct](https://github.com/ory/fosite/blob/master/CODE_OF_CONDUCT.md)."
required: true
- label:
"I have read and am following this repository's [Contribution
Guidelines](https://github.com/ory/fosite/blob/master/CONTRIBUTING.md)."
required: true
- label:
"I have joined the [Ory Community Slack](https://slack.ory.sh)."
- label:
"I am signed up to the [Ory Security Patch
Newsletter](https://www.ory.sh/l/sign-up-newsletter)."
id: checklist
type: checkboxes
- attributes:
description:
"Enter the slug or API URL of the affected Ory Network project. Leave
empty when you are self-hosting."
label: "Ory Network Project"
placeholder: "https://<your-project-slug>.projects.oryapis.com"
id: ory-network-project
type: input
- attributes:
description: |
This section gives the reader a very rough overview of the landscape in which the new system is being built and what is actually being built. This isn’t a requirements doc. Keep it succinct! The goal is that readers are brought up to speed but some previous knowledge can be assumed and detailed info can be linked to. This section should be entirely focused on objective background facts.
label: "Context and scope"
id: scope
type: textarea
validations:
required: true

- attributes:
description: |
A short list of bullet points of what the goals of the system are, and, sometimes more importantly, what non-goals are. Note, that non-goals aren’t negated goals like “The system shouldn’t crash”, but rather things that could reasonably be goals, but are explicitly chosen not to be goals. A good example would be “ACID compliance”; when designing a database, you’d certainly want to know whether that is a goal or non-goal. And if it is a non-goal you might still select a solution that provides it, if it doesn’t introduce trade-offs that prevent achieving the goals.
label: "Goals and non-goals"
id: goals
type: textarea
validations:
required: true

- attributes:
description: |
This section should start with an overview and then go into details.
The design doc is the place to write down the trade-offs you made in designing your software. Focus on those trade-offs to produce a useful document with long-term value. That is, given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals.
The point of writing a document over a more formal medium is to provide the flexibility to express the problem at hand in an appropriate manner. Because of this, there is no explicit guidance on how to actually describe the design.
label: "The design"
id: design
type: textarea
validations:
required: true

- attributes:
description: |
If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead, focus on the parts that are relevant to the design and its trade-offs.
label: "APIs"
id: apis
type: textarea

- attributes:
description: |
Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead, focus on the parts that are relevant to the design and its trade-offs.
label: "Data storage"
id: persistence
type: textarea

- attributes:
description: |
Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the feasibility of the design.
label: "Code and pseudo-code"
id: pseudocode
type: textarea

- attributes:
description: |
One of the primary factors that would influence the shape of a software design and hence the design doc, is the degree of constraint of the solution space.
On one end of the extreme is the “greenfield software project”, where all we know are the goals, and the solution can be whatever makes the most sense. Such a document may be wide-ranging, but it also needs to quickly define a set of rules that allow zooming in on a manageable set of solutions.
On the other end are systems where the possible solutions are very well defined, but it isn't at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn't designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.
In this situation, you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are great, and hence such a document should focus on selecting the best way given all identified trade-offs.
label: "Degree of constraint"
id: constrait
type: textarea

- attributes:
description: |
This section lists alternative designs that would have reasonably achieved similar outcomes. The focus should be on the trade-offs that each respective design makes and how those trade-offs led to the decision to select the design that is the primary topic of the document.
While it is fine to be succinct about a solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.
label: Alternatives considered
id: alternatives
type: textarea
86 changes: 86 additions & 0 deletions .github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# AUTO-GENERATED, DO NOT EDIT!
# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/FEATURE-REQUEST.yml

description:
"Suggest an idea for this project without a plan for implementation"
labels:
- feat
name: "Feature Request"
body:
- attributes:
value: |
Thank you for suggesting an idea for this project!
If you already have a plan to implement a feature or a change, please create a [design document](https://github.com/aeneasr/gh-template-test/issues/new?assignees=&labels=rfc&template=DESIGN-DOC.yml) instead if the change is non-trivial!
type: markdown
- attributes:
label: "Preflight checklist"
options:
- label:
"I could not find a solution in the existing issues, docs, nor
discussions."
required: true
- label:
"I agree to follow this project's [Code of
Conduct](https://github.com/ory/fosite/blob/master/CODE_OF_CONDUCT.md)."
required: true
- label:
"I have read and am following this repository's [Contribution
Guidelines](https://github.com/ory/fosite/blob/master/CONTRIBUTING.md)."
required: true
- label:
"I have joined the [Ory Community Slack](https://slack.ory.sh)."
- label:
"I am signed up to the [Ory Security Patch
Newsletter](https://www.ory.sh/l/sign-up-newsletter)."
id: checklist
type: checkboxes
- attributes:
description:
"Enter the slug or API URL of the affected Ory Network project. Leave
empty when you are self-hosting."
label: "Ory Network Project"
placeholder: "https://<your-project-slug>.projects.oryapis.com"
id: ory-network-project
type: input
- attributes:
description:
"Is your feature request related to a problem? Please describe."
label: "Describe your problem"
placeholder:
"A clear and concise description of what the problem is. Ex. I'm always
frustrated when [...]"
id: problem
type: textarea
validations:
required: true
- attributes:
description: |
Describe the solution you'd like
placeholder: |
A clear and concise description of what you want to happen.
label: "Describe your ideal solution"
id: solution
type: textarea
validations:
required: true
- attributes:
description: "Describe alternatives you've considered"
label: "Workarounds or alternatives"
id: alternatives
type: textarea
validations:
required: true
- attributes:
description: "What version of our software are you running?"
label: Version
id: version
type: input
validations:
required: true
- attributes:
description:
"Add any other context or screenshots about the feature request here."
label: Additional Context
id: additional
type: textarea
27 changes: 0 additions & 27 deletions .github/ISSUE_TEMPLATE/bug_report.md

This file was deleted.

14 changes: 14 additions & 0 deletions .github/ISSUE_TEMPLATE/config.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# AUTO-GENERATED, DO NOT EDIT!
# Please edit the original at https://github.com/ory/meta/blob/master/templates/repository/common/.github/ISSUE_TEMPLATE/config.yml

blank_issues_enabled: false
contact_links:
- name: Ory Fosite Forum
url: https://github.com/orgs/ory/discussions
about:
Please ask and answer questions here, show your implementations and
discuss ideas.
- name: Ory Chat
url: https://www.ory.sh/chat
about:
Hang out with other Ory community members to ask and answer questions.
Loading