matrix.org/static/jira/browse/SPEC-118

70 lines
1.9 KiB
Plaintext

---
summary: v2 login flow representation
---
created: 2015-02-26 17:51:01.0
creator: kegan
description: |-
Consider if a tree-only approach is going to be better than using string arrays.
{code}
Complete stages:
foo -> bar
`--> baz
alice -> bob -> charlie
stages: [
{
type: "foo",
stages: [
{ type: "bar" },
{ type: "baz" }
]
},
{
type: "alice",
stages: [
{
type: "bob",
stages: [
{ type: "charlie" }
]
}
]
}
]
{code}
@eternaleye for suggestion:
{code}
M-kegan: Well, if "next" can be a list, then the sensible thing IMO is to replace the 'stages' list with a 'stages' tree.
M-kegan: Basically, instead of info: [{type, stages}] where stages: [type], have info: [{type, stages}] where stages: info
M-kegan: And then the absence of 'stages' indicates bottoming out on the auth flow.
M-kegan: Plus, if the next key is also an info (for a subtree), then it can just be treated as recursion in clients.
M-kegan: Also, it being a tree would allow stuff like a client library pruning by the auth methods it supports before returning the info to its caller
M-kegan: I guess part of it is that I feel the different representations may be a source of implementation bugs (especially server-side)
M-kegan: Another benefit is that server-side implementations could actually represent the auth setup as a tree, and just have a serializer to generate the appropriate json
{code}
id: '11145'
key: SPEC-118
number: '118'
priority: '2'
project: '10001'
reporter: kegan
status: '10100'
type: '1'
updated: 2016-10-28 16:27:04.0
votes: '0'
watches: '4'
workflowId: '11245'
---
actions:
- author: richvdh
body: 'Migrated to github: https://github.com/matrix-org/matrix-doc/issues/430'
created: 2016-10-28 16:27:04.0
id: '13281'
issue: '11145'
type: comment
updateauthor: richvdh
updated: 2016-10-28 16:27:04.0