urbit/shrub
1
1
Fork 0
mirror of https://github.com/urbit/shrub.git synced 2024-12-21 01:41:37 +03:00
Code Issues Packages Projects Releases Wiki Activity
be0bbc78c5
shrub/pkg/arvo/sys/vane/eyre.hoon

4073 lines
136 KiB
Plaintext
Raw Normal View History

Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
!:
:: lighter than eyre
::
arvo: updates vane interface
2020-12-06 11:38:37 +03:00
|= our=ship
moves +http-server interface core into +eyre
2019-07-04 09:09:44 +03:00
=, eyre
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: internal data structures
::
=> =~
::
:: internal data structures that won't go in zuse
::
|%
+$ move
::
$: :: duct: request identifier
::
=duct
::
::
zuse: lift moves out of +able
2020-12-08 03:47:06 +03:00
card=(wind note gift)
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
==
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
:: +note: private request from eyre to another vane
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
+$ note
eyre: simplify internal $note and $sign type style
2023-06-28 00:15:00 +03:00
$% [%a $>(?(%plea %keen %yawn) task:ames)]
[%b $>(?(%rest %wait) task:behn)]
[%c $>(%warp task:clay)]
[%d $>(%flog task:dill)]
[%g $>(%deal task:gall)]
==
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
:: +sign: private response from another vane to eyre
Send responses.
2018-09-24 21:48:19 +03:00
::
+$ sign
eyre: simplify internal $note and $sign type style
2023-06-28 00:15:00 +03:00
$% [%ames $>(?(%done %boon %lost %tune) gift:ames)]
[%behn $>(%wake gift:behn)]
[%gall gift:gall]
[%clay gift:clay]
==
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
--
:: more structures
::
|%
++ axle
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
$: :: date: date at which http-server's state was updated to this data structure
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
date=%~2023.5.15
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: server-state: state of inbound requests
::
=server-state
==
:: +server-state: state relating to open inbound HTTP connections
::
+$ server-state
$: :: bindings: actions to dispatch to when a binding matches
::
:: Eyre is responsible for keeping its bindings sorted so that it
:: will trigger on the most specific binding first. Eyre should send
:: back an error response if an already bound binding exists.
::
:: TODO: It would be nice if we had a path trie. We could decompose
:: the :binding into a (map (unit @t) (trie knot =action)).
::
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
bindings=(list [=binding =duct =action])
eyre: add cache
2023-03-25 07:18:25 +03:00
:: cache: mapping from url to versioned entry
::
cache=(map url=@t [aeon=@ud val=(unit cache-entry)])
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
:: cors-registry: state used and managed by the +cors core
::
=cors-registry
Send responses.
2018-09-24 21:48:19 +03:00
:: connections: open http connections not fully complete
Messages from %l to %g
2018-09-21 02:36:04 +03:00
::
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
connections=(map duct outstanding-connection)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
:: auth: state managed by the +authentication core
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth=authentication-state
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: channel-state: state managed by the +channel core
::
=channel-state
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
:: domains: domain-names that resolve to us
::
domains=(set turf)
:: http-config: our server configuration
::
=http-config
:: ports: live servers
::
ports=[insecure=@ud secure=(unit @ud)]
updates %rver to save outgoing duct to unix
2019-04-10 00:03:21 +03:00
:: outgoing-duct: to unix
::
outgoing-duct=duct
veb to verb
2023-02-08 23:19:14 +03:00
:: verb: verbosity
trace moved into +per-server-event
2023-02-08 22:43:13 +03:00
::
veb to verb
2023-02-08 23:19:14 +03:00
verb=@
Send responses.
2018-09-24 21:48:19 +03:00
==
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: channel-request: an action requested on a channel
::
+$ channel-request
$% :: %ack: acknowledges that the client has received events up to :id
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
[%ack event-id=@ud]
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
:: %poke: pokes an application, validating :noun against :mark
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
[%poke request-id=@ud ship=@p app=term mark=@tas =noun]
:: %poke-json: pokes an application, translating :json to :mark
::
[%poke-json request-id=@ud ship=@p app=term mark=@tas =json]
mall: rename agent arms
2019-11-07 09:19:32 +03:00
:: %watch: subscribes to an application path
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: fix tests
2019-11-14 06:38:13 +03:00
[%subscribe request-id=@ud ship=@p app=term =path]
mall: rename agent arms
2019-11-07 09:19:32 +03:00
:: %leave: unsubscribes from an application path
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: fix tests
2019-11-14 06:38:13 +03:00
[%unsubscribe request-id=@ud subscription-id=@ud]
Added ability to quit channel from rver
2019-06-14 00:53:04 +03:00
:: %delete: kills a channel
::
[%delete ~]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
==
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:: clog-timeout: the delay between acks after which clog-threshold kicks in
::
++ clog-timeout ~s30
:: clog-threshold: maximum per-subscription event buildup, after clog-timeout
::
++ clog-threshold 50
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
:: channel-timeout: the delay before a channel should be reaped
::
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
++ channel-timeout ~h12
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
:: session-timeout: the delay before an idle session expires
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
::
++ session-timeout ~d7
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
--
:: utilities
::
|%
Multiple event downloading passes tests.
2019-01-30 22:06:24 +03:00
:: +combine-octs: combine multiple octs into one
::
++ combine-octs
|= a=(list octs)
^- octs
:- %+ roll a
|= [=octs sum=@ud]
(add sum p.octs)
(can 3 a)
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
:: +prune-events: removes all items from the front of the queue up to :id
::
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:: also produces, per request-id, the amount of events that have got acked,
:: for use with +subtract-acked-events.
::
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
++ prune-events
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
=| acked=(map @ud @ud)
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
|= [q=(qeu [id=@ud @ud channel-event]) id=@ud]
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
^+ [acked q]
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
:: if the queue is now empty, that's fine
::
Get basic client side event acknowledging working.
2019-01-12 02:18:53 +03:00
?: =(~ q)
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
[acked ~]
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
::
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
=/ next=[item=[id=@ud request-id=@ud channel-event] _q] ~(get to q)
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
:: if the head of the queue is newer than the acknowledged id, we're done
::
Fix event queue and add end-to-end test of the channels, including retry logic.
2019-01-17 01:58:07 +03:00
?: (gth id.item.next id)
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
[acked q]
:: otherwise, note the ack, and check next item
::
%_ $
q +:next
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
::
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
acked
=, item.next
%+ ~(put by acked) request-id
+((~(gut by acked) request-id 0))
==
:: +subtract-acked-events: update the subscription map's pending ack counts
::
++ subtract-acked-events
|= [acked=(map @ud @ud) unacked=(map @ud @ud)]
^+ unacked
%+ roll ~(tap by acked)
|= [[rid=@ud ack=@ud] unacked=_unacked]
?~ sus=(~(get by unacked) rid)
unacked
%+ ~(put by unacked) rid
?: (lte u.sus ack) 0
(sub u.sus ack)
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
:: +find-channel-mode: deduce requested mode from headers
::
++ find-channel-mode
|= [met=method:http hes=header-list:http]
^- ?(%json %jam)
=+ ^- [hed=@t jam=@t]
eyre, mar: use x-urb-jam mime type for jams
2023-04-12 19:42:35 +03:00
?: ?=(%'GET' met) ['x-channel-format' 'application/x-urb-jam']
eyre: use jam mime type for PUT mode detection Making this consistent with the mime type used for GET requests.
2023-04-12 20:19:13 +03:00
['content-type' 'application/x-urb-jam']
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
=+ typ=(bind (get-header:http hed hes) :(cork trip cass crip))
?:(=(`jam typ) %jam %json)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: +parse-channel-request: parses a list of channel-requests
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
++ parse-channel-request
|= [mode=?(%json %jam) body=octs]
^- (each (list channel-request) @t)
?- mode
%json
json: remove deprecated JSON parser calls
2023-06-30 22:25:19 +03:00
?~ maybe-json=(de:json:html q.body)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
|+'put body not json'
?~ maybe-requests=(parse-channel-request-json u.maybe-json)
|+'invalid channel json'
&+u.maybe-requests
::
%jam
?~ maybe-noun=(bind (slaw %uw q.body) cue)
|+'invalid request format'
?~ maybe-reqs=((soft (list channel-request)) u.maybe-noun)
~& [%miss u.maybe-noun]
|+'invalid request data'
&+u.maybe-reqs
==
:: +parse-channel-request-json: parses a json list of channel-requests
::
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
:: Parses a json array into a list of +channel-request. If any of the items
:: in the list fail to parse, the entire thing fails so we can 400 properly
:: to the client.
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
++ parse-channel-request-json
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
|= request-list=json
^- (unit (list channel-request))
:: parse top
::
=, dejs-soft:format
=- ((ar -) request-list)
::
|= item=json
^- (unit channel-request)
::
?~ maybe-key=((ot action+so ~) item)
~
?: =('ack' u.maybe-key)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
((pe %ack (ot event-id+ni ~)) item)
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
?: =('poke' u.maybe-key)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
%. item
%+ pe %poke-json
(ot id+ni ship+(su fed:ag) app+so mark+(su sym) json+some ~)
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
?: =('subscribe' u.maybe-key)
%. item
eyre: fix tests
2019-11-14 06:38:13 +03:00
%+ pe %subscribe
hoon: add +stap, path parser And cleans up a bunch of locally hand-written implementations of it.
2021-04-07 22:14:13 +03:00
(ot id+ni ship+(su fed:ag) app+so path+(su stap) ~)
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
?: =('unsubscribe' u.maybe-key)
%. item
eyre: fix tests
2019-11-14 06:38:13 +03:00
%+ pe %unsubscribe
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
(ot id+ni subscription+ni ~)
Added ability to quit channel from rver
2019-06-14 00:53:04 +03:00
?: =('delete' u.maybe-key)
`[%delete ~]
Parse incoming requests and add tests.
2018-11-16 00:43:10 +03:00
:: if we reached this, we have an invalid action key. fail parsing.
::
~
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
:: +auth-styling: css for login and eauth pages
::
++ auth-styling
'''
@import url("https://rsms.me/inter/inter.css");
@font-face {
font-family: "Source Code Pro";
src: url("https://storage.googleapis.com/media.urbit.org/fonts/scp-regular.woff");
font-weight: 400;
font-display: swap;
}
:root {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
--red-soft: #FFEFEC;
--red: #FF6240;
--gray-100: #E5E5E5;
--gray-400: #999999;
--gray-800: #333333;
--white: #FFFFFF;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
html {
font-family: Inter, sans-serif;
height: 100%;
margin: 0;
width: 100%;
background: var(--white);
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
color: var(--gray-800);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
-webkit-font-smoothing: antialiased;
line-height: 1.5;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
font-size: 16px;
font-weight: 600;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
display: flex;
flex-flow: row nowrap;
justify-content: center;
}
body {
display: flex;
flex-flow: column nowrap;
justify-content: center;
max-width: 300px;
padding: 1rem;
width: 100%;
}
body.local #eauth,
body.eauth #local {
display: none;
min-height: 100%;
}
#eauth input {
/*NOTE dumb hack to get approx equal height with #local */
margin-bottom: 15px;
}
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
body nav {
background: var(--gray-100);
border-radius: 2rem;
display: flex;
justify-content: space-around;
overflow: hidden;
margin-bottom: 1rem;
}
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
body nav div {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
width: 50%;
padding: 0.5rem 1rem;
text-align: center;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
cursor: pointer;
}
body.local nav div.local,
body.eauth nav div.eauth {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--gray-800);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
color: var(--white);
cursor: default;
}
nav div.local {
border-right: none;
border-top-right-radius: 0;
border-bottom-right-radius: 0;
}
nav div.eauth {
border-left: none;
border-top-left-radius: 0;
border-bottom-left-radius: 0;
}
body > *,
form > input {
width: 100%;
}
form {
display: flex;
flex-flow: column;
align-items: flex-start;
}
input {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--gray-100);
border: 2px solid transparent;
padding: 0.5rem;
border-radius: 0.5rem;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
font-size: inherit;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
color: var(--gray-800);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
box-shadow: none;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
width: 100%;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
input:disabled {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--gray-100);
color: var(--gray-400);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
input:focus {
outline: none;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--white);
border-color: var(--gray-400);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
input:invalid:not(:focus) {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--red-soft);
border-color: var(--red);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
outline: none;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
color: var(--red);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
button[type=submit] {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
margin-top: 1rem;
font-size: 1rem;
padding: 0.5rem 1rem;
border-radius: 0.5rem;
background: var(--gray-800);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
color: var(--white);
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
border: none;
font-weight: 600;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
input:invalid ~ button[type=submit] {
border-color: currentColor;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
background: var(--gray-100);
color: var(--gray-400);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
pointer-events: none;
}
span.guest {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
color: var(--gray-400);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
span.failed {
display: flex;
flex-flow: row nowrap;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
height: 1rem;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
align-items: center;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
margin-top: 0.875rem;
color: var(--red);
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
span.failed svg {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
height: 1rem;
margin-right: 0.25rem;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
span.failed path {
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
fill: transparent;
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
stroke-width: 2px;
stroke-linecap: round;
stroke: currentColor;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
.mono {
font-family: 'Source Code Pro', monospace;
}
@media all and (prefers-color-scheme: dark) {
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
:root {
--white: #000000;
--gray-800: #E5E5E5;
--gray-400: #808080;
--gray-100: #333333;
--red-soft: #7F1D1D;
}
}
@media screen and (min-width: 30em) {
html {
font-size: 14px;
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
}
}
'''
More complete login flow
2018-09-27 02:18:40 +03:00
:: +login-page: internal page to login to an Urbit
::
++ login-page
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
|= [redirect-url=(unit @t) our=@p =identity eauth=(unit ?) failed=?]
More complete login flow
2018-09-27 02:18:40 +03:00
^- octs
=+ redirect-str=?~(redirect-url "" (trip u.redirect-url))
%- as-octs:mimes:html
%- crip
%- en-xml:html
eyre: translate login to indigo fixes https://github.com/urbit/landscape/issues/154
2020-12-03 06:36:39 +03:00
=/ favicon %+
weld "<svg width='10' height='10' viewBox='0 0 10 10' xmlns='http://www.w3.org/2000/svg'>"
"<circle r='3.09' cx='5' cy='5' /></svg>"
More complete login flow
2018-09-27 02:18:40 +03:00
;html
;head
Styled login page within rver for modulo
2019-07-02 01:16:52 +03:00
;meta(charset "utf-8");
eyre: add new os1 login screen
2020-02-11 03:48:47 +03:00
;meta(name "viewport", content "width=device-width, initial-scale=1, shrink-to-fit=no");
eyre: translate login to indigo fixes https://github.com/urbit/landscape/issues/154
2020-12-03 06:36:39 +03:00
;link(rel "icon", type "image/svg+xml", href (weld "data:image/svg+xml;utf8," favicon));
eyre: Modify landing title from "OS1" to "Urbit"
2022-05-29 23:22:20 +03:00
;title:"Urbit"
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
;style:"{(trip auth-styling)}"
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
;style:"{?^(eauth "" "nav \{ display: none; }")}"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;script:"our = '{(scow %p our)}';"
;script:'''
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
let name, pass;
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
function setup(isEauth) {
name = document.getElementById('name');
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
pass = document.getElementById('pass');
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
if (isEauth) goEauth(); else goLocal();
}
function goLocal() {
document.body.className = 'local';
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
pass.focus();
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
function goEauth() {
document.body.className = 'eauth';
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
name.focus();
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
function doEauth() {
console.log('mb get value from event', event);
console.log('compare', name.value, our);
if (name.value == our) {
event.preventDefault();
goLocal();
}
}
'''
More complete login flow
2018-09-27 02:18:40 +03:00
==
;body
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
=class "{?:(=(`& eauth) "eauth" "local")}"
=onload "setup({?:(=(`& eauth) "true" "false")})"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;nav
;div.local(onclick "goLocal()"):"Local"
;div.eauth(onclick "goEauth()"):"EAuth"
==
;div#local
;p:"Urbit ID"
;input(value "{(scow %p our)}", disabled "true", class "mono");
;p:"Access Key"
;form(action "/~/login", method "post", enctype "application/x-www-form-urlencoded")
;input
=type "password"
=name "password"
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
=id "pass"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=placeholder "sampel-ticlyt-migfun-falmel"
=class "mono"
=required "true"
=minlength "27"
=maxlength "27"
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
=pattern "((?:[a-z]\{6}-)\{3}(?:[a-z]\{6}))";
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;input(type "hidden", name "redirect", value redirect-str);
;+ ?. failed ;span;
;span.failed
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
;svg(xmlns "http://www.w3.org/2000/svg", viewBox "0 0 16 16")
;path(d "m8 8 4-4M8 8 4 4m4 4-4 4m4-4 4 4");
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
Key is incorrect
eyre: add new os1 login screen
2020-02-11 03:48:47 +03:00
==
eyre: translate login to indigo fixes https://github.com/urbit/landscape/issues/154
2020-12-03 06:36:39 +03:00
;button(type "submit"):"Continue"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
==
;div#eauth
;form(action "/~/login", method "post", onsubmit "return doEauth()")
;p:"Urbit ID"
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
;input.mono
=name "name"
=id "name"
=placeholder "{(scow %p our)}"
=required "true"
=minlength "4"
=maxlength "57"
=pattern "~((([a-z]\{6})\{1,2}-\{0,2})+|[a-z]\{3})";
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;p
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
; You will be redirected to your own web interface to authorize
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
; logging in to
;span.mono:"{(scow %p our)}"
; .
==
;input(type "hidden", name "redirect", value redirect-str);
eyre: cosmetic updates to login form Makes cosmetic changes to the login page of eyre. This addresses an issue with insufficient contrast between text elements and their backgrounds in dark mode.
2023-07-25 00:23:01 +03:00
;button(name "eauth", type "submit"):"Continue"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
More complete login flow
2018-09-27 02:18:40 +03:00
==
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
;* ?. ?=(%fake -.identity) ~
=+ id=(trim 29 (scow %p who.identity))
;+ ;span.guest.mono
; Current guest identity:
;br;
; {p.id}
;br;
; {q.id}
==
More complete login flow
2018-09-27 02:18:40 +03:00
==
eyre: translate login to indigo fixes https://github.com/urbit/landscape/issues/154
2020-12-03 06:36:39 +03:00
;script:'''
var failSpan = document.querySelector('.failed');
if (failSpan) {
document.querySelector("input[type=password]")
.addEventListener('keyup', function (event) {
failSpan.style.display = 'none';
});
}
'''
More complete login flow
2018-09-27 02:18:40 +03:00
==
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
:: +eauth-error-page: render an eauth error reporting page
::
:: optionally redirects the user back to either the login page if we're
:: acting as server, or the host if we're the client.
::
++ eauth-error-page
|= $= return
$? ~ :: no known return target
[%server last=@t] :: we are the host, return to login
[%client goal=@t] :: we are the client, return to host
==
^- octs
%- as-octs:mimes:html
%- crip
%- en-xml:html
=/ return=(unit @t)
?- return
~ ~
[%server *] %- some
%^ cat 3 '/~/login?eauth&redirect='
(crip (en-urlt:html (trip last.return)))
[%client *] `goal.return ::TODO plus nonce? or abort?
==
=/ favicon %+
weld "<svg width='10' height='10' viewBox='0 0 10 10' xmlns='http://www.w3.org/2000/svg'>"
"<circle r='3.09' cx='5' cy='5' /></svg>"
=/ msg=tape
?~ return "Something went wrong!"
"Something went wrong! You will be redirected back..."
;html
;head
;* ?~ return ~
:_ ~
;meta(http-equiv "Refresh", content "5; url={(trip u.return)}");
;meta(charset "utf-8");
;meta(name "viewport", content "width=device-width, initial-scale=1, shrink-to-fit=no");
;link(rel "icon", type "image/svg+xml", href (weld "data:image/svg+xml;utf8," favicon));
;title:"Urbit"
;style:'''
@import url("https://rsms.me/inter/inter.css");
:root {
--black60: rgba(0,0,0,0.6);
--white: rgba(255,255,255,1);
}
html {
font-family: Inter, sans-serif;
height: 100%;
margin: 0;
width: 100%;
background: var(--white);
color: var(--black60);
-webkit-font-smoothing: antialiased;
line-height: 1.5;
font-size: 12px;
display: flex;
flex-flow: row nowrap;
justify-content: center;
}
body {
display: flex;
flex-flow: column nowrap;
justify-content: center;
max-width: 300px;
padding: 1rem;
width: 100%;
}
'''
==
;body:"{msg}"
==
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: +render-tang-to-marl: renders a tang and adds <br/> tags between each line
First generator build ran.
2018-10-11 01:26:51 +03:00
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
++ render-tang-to-marl
various: move away from {type} syntax In favor of [type] syntax. Turns a bunch of ++ into +$ along the way.
2020-11-26 17:09:31 +03:00
|= [wid=@u tan=tang]
First generator build ran.
2018-10-11 01:26:51 +03:00
^- marl
various: move away from face/type syntax In favor of face=type.
2020-11-25 23:22:55 +03:00
=/ raw=(list tape) (zing (turn tan |=(a=tank (wash 0^wid a))))
First generator build ran.
2018-10-11 01:26:51 +03:00
::
|- ^- marl
?~ raw ~
[;/(i.raw) ;br; $(raw t.raw)]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: +render-tang-to-wall: renders tang as text lines
::
++ render-tang-to-wall
various: move away from {type} syntax In favor of [type] syntax. Turns a bunch of ++ into +$ along the way.
2020-11-26 17:09:31 +03:00
|= [wid=@u tan=tang]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
^- wall
(zing (turn tan |=(a=tank (wash 0^wid a))))
:: +wall-to-octs: text to binary output
::
++ wall-to-octs
|= =wall
^- (unit octs)
::
?: =(~ wall)
~
::
:- ~
%- as-octs:mimes:html
%- crip
eyre: faster wain-to-octs conversion Avoid allocating hundreds of thousands of cells when giving large requests. This took the footprint of this function on initial landscape load from 1 second to 100 ms.
2021-03-28 10:57:33 +03:00
%- zing ^- ^wall
%- zing ^- (list ^wall)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
%+ turn wall
|= t=tape
eyre: faster wain-to-octs conversion Avoid allocating hundreds of thousands of cells when giving large requests. This took the footprint of this function on initial landscape load from 1 second to 100 ms.
2021-03-28 10:57:33 +03:00
^- ^wall
~[t "\0a"]
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
:: +internal-server-error: 500 page, with a tang
::
++ internal-server-error
First generator build ran.
2018-10-11 01:26:51 +03:00
|= [authorized=? url=@t t=tang]
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
^- octs
%- as-octs:mimes:html
%- crip
%- en-xml:html
;html
;head
;title:"500 Internal Server Error"
==
;body
;h1:"Internal Server Error"
eyre: forego <atom> in favor of (scow %aura atom) Pretty-printing is expensive, yet we do it whenever we construct the cookie string, at least once (but usually twice) per authenticated request. Here we call out the the specific to-tape functions we need, instead of relying on the pretty-printer for converting... tapes to tapes, among other things. The primary gains come from the cookie-related instances, we update the others mostly for good style. For the "receive request and immediately send response" case, that is processed synchronously within eyre (ie, client sends channel ack), speeds thing up by roughly 55%.
2020-11-04 03:02:11 +03:00
;p:"There was an error while handling the request for {(trip url)}."
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
;* ?: authorized
;=
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
;code:"*{(render-tang-to-marl 80 t)}"
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
==
~
==
==
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
:: +error-page: error page, with an error string if logged in
Actually have a 400 Bad Request page instead of reusing the 500 page incorrectly.
2019-03-21 02:00:46 +03:00
::
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
++ error-page
|= [code=@ud authorized=? url=@t t=tape]
Actually have a 400 Bad Request page instead of reusing the 500 page incorrectly.
2019-03-21 02:00:46 +03:00
^- octs
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
::
=/ code-as-tape=tape (format-ud-as-integer code)
=/ message=tape
eyre: forego <atom> in favor of (scow %aura atom) Pretty-printing is expensive, yet we do it whenever we construct the cookie string, at least once (but usually twice) per authenticated request. Here we call out the the specific to-tape functions we need, instead of relying on the pretty-printer for converting... tapes to tapes, among other things. The primary gains come from the cookie-related instances, we update the others mostly for good style. For the "receive request and immediately send response" case, that is processed synchronously within eyre (ie, client sends channel ack), speeds thing up by roughly 55%.
2020-11-04 03:02:11 +03:00
?+ code "{(scow %ud code)} Error"
eyre: slightly better error pages
2020-06-12 03:13:13 +03:00
%400 "Bad Request"
%403 "Forbidden"
%404 "Not Found"
%405 "Method Not Allowed"
%500 "Internal Server Error"
==
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
::
Actually have a 400 Bad Request page instead of reusing the 500 page incorrectly.
2019-03-21 02:00:46 +03:00
%- as-octs:mimes:html
%- crip
%- en-xml:html
;html
;head
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
;title:"{code-as-tape} {message}"
Actually have a 400 Bad Request page instead of reusing the 500 page incorrectly.
2019-03-21 02:00:46 +03:00
==
;body
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
;h1:"{message}"
eyre: forego <atom> in favor of (scow %aura atom) Pretty-printing is expensive, yet we do it whenever we construct the cookie string, at least once (but usually twice) per authenticated request. Here we call out the the specific to-tape functions we need, instead of relying on the pretty-printer for converting... tapes to tapes, among other things. The primary gains come from the cookie-related instances, we update the others mostly for good style. For the "receive request and immediately send response" case, that is processed synchronously within eyre (ie, client sends channel ack), speeds thing up by roughly 55%.
2020-11-04 03:02:11 +03:00
;p:"There was an error while handling the request for {(trip url)}."
Actually have a 400 Bad Request page instead of reusing the 500 page incorrectly.
2019-03-21 02:00:46 +03:00
;* ?: authorized
;=
;code:"{t}"
==
~
==
==
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
:: +format-ud-as-integer: prints a number for consumption outside urbit
::
++ format-ud-as-integer
|= a=@ud
Remove implicit +sell On each wakeup during send in light, we were spending about 7ms inside +sell. Replace that with an equivalent way of printing an integer to a tape. We now spend about half a ms on each outbound message.
2019-01-17 02:24:30 +03:00
^- tape
?: =(0 a) ['0' ~]
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
%- flop
|- ^- tape
?:(=(0 a) ~ [(add '0' (mod a 10)) $(a (div a 10))])
Change host matching so ~ will match any inbound.
2019-06-04 00:34:01 +03:00
:: +host-matches: %.y if the site :binding should be used to handle :host
::
++ host-matches
|= [binding=(unit @t) host=(unit @t)]
^- ?
:: if the binding allows for matching anything, match
::
?~ binding
%.y
:: if the host is ~, that means we're trying to bind nothing to a real
:: binding. fail.
::
?~ host
%.n
:: otherwise, do a straight comparison
::
=(u.binding u.host)
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
:: +find-suffix: returns [~ /tail] if :full is (weld :prefix /tail)
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
::
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
++ find-suffix
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
|= [prefix=path full=path]
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
^- (unit path)
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
?~ prefix
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
`full
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
?~ full
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
~
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
?. =(i.prefix i.full)
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
~
Fix path dispatch so root generators work.
2018-10-11 21:28:27 +03:00
$(prefix t.prefix, full t.full)
Fix url parser and add tests.
2018-10-04 00:05:36 +03:00
:: +simplified-url-parser: returns [(each @if @t) (unit port=@ud)]
::
++ simplified-url-parser
;~ plug
;~ pose
%+ stag %ip
=+ tod=(ape:ag ted:ab)
%+ bass 256
;~(plug tod (stun [3 3] ;~(pfix dot tod)))
::
(stag %site (cook crip (star ;~(pose dot alp))))
==
;~ pose
(stag ~ ;~(pfix col dim:ag))
(easy ~)
==
==
eyre: simplify auto-https logic
2022-09-24 12:52:34 +03:00
:: +host-sans-port: strip the :<port> from a host string
::
++ host-sans-port
;~ sfix
%+ cook crip
%- star
;~ less
;~(plug col (punt dem) ;~(less next (easy ~)))
next
==
(star next)
==
Start filling out the request data structures.
2018-10-26 02:32:54 +03:00
:: +per-server-event: per-event server core
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
++ per-server-event
eyre: cast within zapgar to avoid nest check
2021-06-15 00:15:45 +03:00
~% %eyre-per-server-event ..part ~
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: gate that produces the +per-server-event core from event information
::
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
|= [[eny=@ =duct now=@da rof=roof] state=server-state]
eyre: change id format
2019-11-14 00:39:29 +03:00
=/ eyre-id (scot %ta (cat 3 'eyre_' (scot %uv (sham duct))))
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
|%
adds rver side of localhost backdoor lens app stub
2019-04-30 23:38:40 +03:00
:: +request-local: bypass authentication for local lens connections
::
++ request-local
|= [secure=? =address =request:http]
^- [(list move) server-state]
::
=/ act [%app app=%lens]
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
::
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
=/ connection=outstanding-connection
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[act [& secure address request] [*@uv [%ours ~]] ~ 0]
adds rver side of localhost backdoor lens app stub
2019-04-30 23:38:40 +03:00
::
=. connections.state
style fixes
2023-02-09 01:03:02 +03:00
%. (~(put by connections.state) duct connection)
changed messages
2023-02-09 20:55:08 +03:00
(trace 2 |.("{<duct>} creating local"))
adds rver side of localhost backdoor lens app stub
2019-04-30 23:38:40 +03:00
::
:_ state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(subscribe-to-app [%ours ~] app.act inbound-request.connection)
Messages from %l to %g
2018-09-21 02:36:04 +03:00
:: +request: starts handling an inbound http request
::
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
++ request
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
|= [secure=? =address =request:http]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
^- [(list move) server-state]
eyre: explicitly permit proposed request in cors Instead of always providing a wildcard for the allowed methods and headers, now echoes back the method and headers that the client asked for, if any. Fixes #3676.
2020-10-09 15:07:05 +03:00
=* headers header-list.request
eyre: respect "forwarded" header from localhost For request transparency, HTTP proxies may set the Forwarded header to specify who the original requester is. For requests from localhost only, we make Eyre respect the Forwarded header, and adjust the handled ip address accordingly. Note that we do not support X-Forwarded or other non-standard variants. The header remains in the request, so server applications can handle them as desired. Fixes #2723.
2020-05-31 18:43:35 +03:00
:: for requests from localhost, respect the "forwarded" header
::
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
=/ [secure=? =^address]
=* same [secure address]
?. =([%ipv4 .127.0.0.1] address) same
?~ forwards=(forwarded-params headers) same
:- (fall (forwarded-secure u.forwards) secure)
(fall (forwarded-for u.forwards) address)
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
eyre: explicitly permit proposed request in cors Instead of always providing a wildcard for the allowed methods and headers, now echoes back the method and headers that the client asked for, if any. Fixes #3676.
2020-10-09 15:07:05 +03:00
=/ host (get-header:http 'host' headers)
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
=/ [=action suburl=@t]
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
(get-action-for-binding host url.request)
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::TODO we might want to mint new identities only for requests that end
:: up going into userspace, not the ones that get handled by eyre.
:: perhaps that distinction, where userspace requests are async, but
:: eyre-handled requests are always synchronous, provides a fruitful
:: angle for refactoring...
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=^ [suv=@uv =identity som=(list move)] state
(session-for-request:authentication request)
=; [moz=(list move) sat=server-state]
[(weld som moz) sat]
::
=/ authenticated ?=(%ours -.identity)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: if we have no eauth endpoint yet, and the request is authenticated,
:: deduce it from the hostname
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=? endpoint.auth.state
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?& authenticated
?=(^ host)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?=(~ auth.endpoint.auth.state)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
%- (trace 2 |.("eauth: storing endpoint at {(trip u.host)}"))
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:+ user.endpoint.auth.state
`(cat 3 ?:(secure 'https://' 'http://') u.host)
now
Messages from %l to %g
2018-09-21 02:36:04 +03:00
:: record that we started an asynchronous response
::
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
=/ connection=outstanding-connection
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[action [authenticated secure address request] [suv identity] ~ 0]
The authenticated access flow works from an app in browser.
2018-10-25 00:31:19 +03:00
=. connections.state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: NB: required by +handle-response and +handle-request:authentication.
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: XX optimize, not all requests are asynchronous
eyre: corrects connection lifecycle comment
2023-05-04 01:40:22 +03:00
::
The authenticated access flow works from an app in browser.
2018-10-25 00:31:19 +03:00
(~(put by connections.state) duct connection)
Update pkg/arvo/sys/vane/eyre.hoon Co-authored-by: fang <git@fang.io>
2022-09-29 03:31:47 +03:00
:: redirect to https if insecure, redirects enabled
:: and secure port live
eyre: add auto-https redirects if a cert is configured and a secure port is live it will set the redirect flag in http-config.state. When it gets a ++request it will return a 301 redirect to https://[host]/[path] if: 1. not already secure 2. redirect flag set 3. secure port live 4. is not requesting /.well-known/acme-challenge/... 5. the host is in domains.state It will not happen if forwarded-secured, localhost, local loopback, ip addresses or domains not in domains.state. in ++load it checks the secure port is live and a cert is set and enables it if so (for people who already use in-urbit letencrypt) %rule %cert tasks also toggle it (only turning it on if secure port live) %live tasks also toggle it (only turning it on if cert set) Have tested with a couple of ships and seems to work fine. This is useful in combination with pyry's auto arvo.network dns config system - can finally get rid of reverse proxies entirely.
2022-09-03 17:58:09 +03:00
::
?: ?& !secure
redirect.http-config.state
?=(^ secure.ports.state)
==
=/ location=@t
eyre: change (cury cat 3) to rap in https redirect
2022-10-01 12:31:59 +03:00
%+ rap 3
:~ 'https://'
(rash (fall host '') host-sans-port)
?: =(443 u.secure.ports.state)
''
(crip ":{(a-co:co u.secure.ports.state)}")
?: ?=([[~ ~] ~] (parse-request-line url.request))
'/'
url.request
eyre: add auto-https redirects if a cert is configured and a secure port is live it will set the redirect flag in http-config.state. When it gets a ++request it will return a 301 redirect to https://[host]/[path] if: 1. not already secure 2. redirect flag set 3. secure port live 4. is not requesting /.well-known/acme-challenge/... 5. the host is in domains.state It will not happen if forwarded-secured, localhost, local loopback, ip addresses or domains not in domains.state. in ++load it checks the secure port is live and a cert is set and enables it if so (for people who already use in-urbit letencrypt) %rule %cert tasks also toggle it (only turning it on if secure port live) %live tasks also toggle it (only turning it on if cert set) Have tested with a couple of ships and seems to work fine. This is useful in combination with pyry's auto arvo.network dns config system - can finally get rid of reverse proxies entirely.
2022-09-03 17:58:09 +03:00
==
%- handle-response
:* %start
:- status-code=301
headers=['location' location]~
data=~
complete=%.y
==
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
:: figure out whether this is a cors request,
:: whether the origin is approved or not,
:: and maybe add it to the "pending approval" set
::
=/ origin=(unit origin)
eyre: explicitly permit proposed request in cors Instead of always providing a wildcard for the allowed methods and headers, now echoes back the method and headers that the client asked for, if any. Fixes #3676.
2020-10-09 15:07:05 +03:00
(get-header:http 'origin' headers)
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
=^ cors-approved requests.cors-registry.state
=, cors-registry.state
?~ origin [| requests]
?: (~(has in approved) u.origin) [& requests]
?: (~(has in rejected) u.origin) [| requests]
[| (~(put in requests) u.origin)]
:: if this is a cors preflight request from an approved origin
:: handle it synchronously
::
?: &(?=(^ origin) cors-approved ?=(%'OPTIONS' method.request))
%- handle-response
=; =header-list:http
[%start [204 header-list] ~ &]
eyre: explicitly permit proposed request in cors Instead of always providing a wildcard for the allowed methods and headers, now echoes back the method and headers that the client asked for, if any. Fixes #3676.
2020-10-09 15:07:05 +03:00
:: allow the method and headers that were asked for,
:: falling back to wildcard if none specified
::
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
::NOTE +handle-response will add the rest of the headers
eyre: explicitly permit proposed request in cors Instead of always providing a wildcard for the allowed methods and headers, now echoes back the method and headers that the client asked for, if any. Fixes #3676.
2020-10-09 15:07:05 +03:00
::
:~ :- 'Access-Control-Allow-Methods'
=- (fall - '*')
(get-header:http 'access-control-request-method' headers)
::
:- 'Access-Control-Allow-Headers'
=- (fall - '*')
(get-header:http 'access-control-request-headers' headers)
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
==
eyre: add cache
2023-03-25 07:18:25 +03:00
:: handle requests to the cache
::
=/ entry (~(get by cache.state) url.request)
?: &(?=(^ entry) ?=(%'GET' method.request))
(handle-cache-req authenticated request val.u.entry)
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
::
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
?- -.action
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
%gen
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
=/ bek=beak [our desk.generator.action da+now]
arvo: unflop the spur in scry No longer use reversed paths in sley-style peek handling.
2020-11-22 00:04:18 +03:00
=/ sup=spur path.generator.action
gall: implement local provenance
2023-05-22 16:12:09 +03:00
=/ ski (rof ~ /eyre %ca bek sup)
eyre: fix tests
2020-05-08 08:29:25 +03:00
=/ cag=cage (need (need ski))
?> =(%vase p.cag)
=/ gat=vase !<(vase q.cag)
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
=/ res=toon
gall: implement local provenance
2023-05-22 16:12:09 +03:00
%- mock :_ (look rof ~ /eyre)
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
:_ [%9 2 %0 1] |.
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
%+ slam
%+ slam gat
eyre: give all args to generators fixes #3082
2020-07-03 00:41:59 +03:00
!>([[now=now eny=eny bek=bek] ~ ~])
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::TODO should get passed the requester's identity
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
!>([authenticated request])
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
?: ?=(%2 -.res)
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
=+ connection=(~(got by connections.state) duct)
%^ return-static-data-on-duct 500 'text/html'
%: internal-server-error
authenticated.inbound-request.connection
url.request.inbound-request.connection
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
leaf+"generator crashed"
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
p.res
==
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
?: ?=(%1 -.res)
=+ connection=(~(got by connections.state) duct)
%^ return-static-data-on-duct 500 'text/html'
%: internal-server-error
authenticated.inbound-request.connection
url.request.inbound-request.connection
leaf+"scry blocked on"
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
(fall (bind (bind ((soft path) p.res) smyt) (late ~)) ~)
eyre: give scry function to generators In Ford Fusion, Clay builds generators but Dojo and Eyre run them. Dojo is already virtualized with a scry function, so +mule is fine, but Eyre is not, so Eyre needs to use +mock and explicitly supply the scry function. This does that. Fortunately, the produced result is simple and easily clammable. Fixes #3089
2020-07-03 08:08:38 +03:00
==
=/ result ;;(simple-payload:http +.p.res)
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
:: ensure we have a valid content-length header
Messages from %l to %g
2018-09-21 02:36:04 +03:00
::
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
:: We pass on the response and the headers the generator produces, but
:: ensure that we have a single content-length header set correctly in
:: the returned if this has a body, and has no content-length if there
:: is no body returned to the client.
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
::
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
=. headers.response-header.result
?~ data.result
(delete-header:http 'content-length' headers.response-header.result)
First generator build ran.
2018-10-11 01:26:51 +03:00
::
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
%^ set-header:http 'content-length'
(crip (format-ud-as-integer p.u.data.result))
headers.response-header.result
::
%- handle-response
^- http-event:http
:* %start
response-header.result
data.result
complete=%.y
==
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
%app
Messages from %l to %g
2018-09-21 02:36:04 +03:00
:_ state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(subscribe-to-app identity app.action inbound-request.connection)
More complete login flow
2018-09-27 02:18:40 +03:00
::
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%authentication
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(handle-request:authentication secure host address [suv identity] request)
::
%eauth
(on-request:eauth:authentication [suv identity] request)
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
::
%logout
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
(handle-logout:authentication [suv identity] request)
WIP: Dump so I can go fix 881.
2018-11-13 22:12:59 +03:00
::
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%channel
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(handle-request:by-channel [suv identity] address request)
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
::
%scry
(handle-scry authenticated address request(url suburl))
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
::
%name
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
(handle-name identity request)
::
%host
%^ return-static-data-on-duct 200 'text/plain'
(as-octs:mimes:html (scot %p our))
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
::
%four-oh-four
%^ return-static-data-on-duct 404 'text/html'
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
(error-page 404 authenticated url.request ~)
More complete login flow
2018-09-27 02:18:40 +03:00
==
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
:: +handle-name: respond with the requester's @p
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
::
++ handle-name
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
|= [=identity =request:http]
^- (quip move server-state)
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
?. =(%'GET' method.request)
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
%^ return-static-data-on-duct 405 'text/html'
(error-page 405 & url.request "may only GET name")
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
%^ return-static-data-on-duct 200 'text/plain'
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=/ nom=@p
?+(-.identity who.identity %ours our)
(as-octs:mimes:html (scot %p nom))
eyre: add cache
2023-03-25 07:18:25 +03:00
:: +handle-cache-req: respond with cached value, 404 or 500
::
++ handle-cache-req
|= [authenticated=? =request:http entry=(unit cache-entry)]
|^ ^- (quip move server-state)
?~ entry
(error-response 404 "cache entry for that binding was deleted")
?: &(auth.u.entry !authenticated)
(error-response 403 ~)
=* body body.u.entry
?- -.body
%payload
%- handle-response
:* %start
response-header.simple-payload.body
data.simple-payload.body
complete=%.y
==
==
::
++ error-response
|= [status=@ud =tape]
^- (quip move server-state)
%^ return-static-data-on-duct status 'text/html'
(error-page status authenticated url.request tape)
--
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
:: +handle-scry: respond with scry result, 404 or 500
::
++ handle-scry
|= [authenticated=? =address =request:http]
|^ ^- (quip move server-state)
eyre: only allow authenticated GET scry requests Lacking any other permissioning mechanism, we must simply reject unauthenticated HTTP-scry requests for now.
2020-06-12 01:57:25 +03:00
?. authenticated
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
(error-response 403 ~)
eyre: only allow authenticated GET scry requests Lacking any other permissioning mechanism, we must simply reject unauthenticated HTTP-scry requests for now.
2020-06-12 01:57:25 +03:00
?. =(%'GET' method.request)
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
(error-response 405 "may only GET scries")
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
:: make sure the path contains an app to scry into
::
=+ req=(parse-request-line url.request)
?. ?=(^ site.req)
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
(error-response 400 "scry path must start with app name")
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
:: attempt the scry that was asked for
::
=/ res=(unit (unit cage))
gall: do mark conversion in +ap-peek Attempt to convert the scry result to the mark that was asked for, failing the scry (with ~) if the conversion fails. Eyre's scry logic, then, can pass the requested mark directly into gall.
2020-06-12 03:03:55 +03:00
(do-scry %gx i.site.req (snoc t.site.req (fall ext.req %mime)))
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
?~ res (error-response 500 "failed scry")
?~ u.res (error-response 404 "no scry result")
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
=* mark p.u.u.res
=* vase q.u.u.res
eyre: keep json to mime tube warm in handle-scry
2023-06-15 18:30:51 +03:00
?: =(%mime mark)
=/ =mime !<(mime vase)
%^ return-static-data-on-duct 200
(rsh 3 (spat p.mime)) q.mime
gall: do mark conversion in +ap-peek Attempt to convert the scry result to the mark that was asked for, failing the scry (with ~) if the conversion fails. Eyre's scry logic, then, can pass the requested mark directly into gall.
2020-06-12 03:03:55 +03:00
:: attempt to find conversion gate to mime
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
::
eyre: keep json to mime tube warm in handle-scry
2023-06-15 18:30:51 +03:00
=/ tub=(unit [tub=tube:clay mov=move])
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
(find-tube i.site.req mark %mime)
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
?~ tub (error-response 500 "no tube from {(trip mark)} to mime")
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
:: attempt conversion, then send results
::
=/ mym=(each mime tang)
eyre: keep json to mime tube warm in handle-scry
2023-06-15 18:30:51 +03:00
(mule |.(!<(mime (tub.u.tub vase))))
=^ cards state
?- -.mym
%| (error-response 500 "failed tube from {(trip mark)} to mime")
%& %+ return-static-data-on-duct 200
[(rsh 3 (spat p.p.mym)) q.p.mym]
==
[[mov.u.tub cards] state]
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
::
++ find-tube
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
|= [dap=term from=mark to=mark]
eyre: keep json to mime tube warm in handle-scry
2023-06-15 18:30:51 +03:00
^- (unit [tube:clay move])
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
=/ des=(unit (unit cage))
arvo: fix %gall meta-namespace reads (missed in merge)
2023-04-27 03:25:23 +03:00
(do-scry %gd dap /$)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
?. ?=([~ ~ *] des) ~
=+ !<(=desk q.u.u.des)
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
=/ tub=(unit (unit cage))
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
(do-scry %cc desk /[from]/[to])
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
?. ?=([~ ~ %tube *] tub) ~
eyre: keep json to mime tube warm in handle-scry
2023-06-15 18:30:51 +03:00
:- ~
:- !<(tube:clay q.u.u.tub)
:^ duct %pass /conversion-cache/[from]
[%c %warp our desk `[%sing %c da+now /[from]/[to]]]
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
::
++ do-scry
|= [care=term =desk =path]
^- (unit (unit cage))
gall: implement local provenance
2023-05-22 16:12:09 +03:00
(rof ~ /eyre care [our desk da+now] path)
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
::
eyre: revert +error-response refactor
2022-08-11 19:30:37 +03:00
++ error-response
|= [status=@ud =tape]
^- (quip move server-state)
%^ return-static-data-on-duct status 'text/html'
(error-page status authenticated url.request tape)
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
--
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
:: +subscribe-to-app: subscribe to app and poke it with request data
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
::
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
++ subscribe-to-app
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [=identity app=term =inbound-request:eyre]
mall, eyre: refactor server apps to be stateless
2019-11-13 11:38:35 +03:00
^- (list move)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:~ %+ deal-as
/watch-response/[eyre-id]
[identity our app %watch /http-response/[eyre-id]]
::
%+ deal-as
/run-app-request/[eyre-id]
:^ identity our app
:+ %poke %handle-http-request
!>(`[@ta inbound-request:eyre]`[eyre-id inbound-request])
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
==
Server side events sorta work.
2018-10-22 21:36:30 +03:00
:: +cancel-request: handles a request being externally aborted
::
++ cancel-request
^- [(list move) server-state]
::
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
?~ connection=(~(get by connections.state) duct)
:: nothing has handled this connection
::
[~ state]
::
Cleanup our ford builds.
2018-10-24 01:08:17 +03:00
=. connections.state (~(del by connections.state) duct)
::
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
?- -.action.u.connection
eyre: use ford-fusion; compiles, untested
2020-05-05 08:28:37 +03:00
%gen [~ state]
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
%app
:_ state
:_ ~
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=, u.connection
%- (trace 1 |.("leaving subscription to {<app.action>}"))
(deal-as /watch-response/[eyre-id] identity our app.action %leave ~)
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?(%authentication %eauth %logout)
::NOTE expiry timer will clean up cancelled eauth attempts
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
[~ state]
WIP: Dump so I can go fix 881.
2018-11-13 22:12:59 +03:00
::
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%channel
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
on-cancel-request:by-channel
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
::
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
?(%scry %four-oh-four %name %host)
:: it should be impossible for these to be asynchronous
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
::
!!
Now responds to http close requests; kills timer sessions.
2018-10-24 00:25:20 +03:00
==
More complete login flow
2018-09-27 02:18:40 +03:00
:: +return-static-data-on-duct: returns one piece of data all at once
::
++ return-static-data-on-duct
|= [code=@ content-type=@t data=octs]
^- [(list move) server-state]
::
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
%- handle-response
:* %start
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:- status-code=code
More complete login flow
2018-09-27 02:18:40 +03:00
^= headers
Lower case http header names; it is allowed.
2018-10-01 21:37:30 +03:00
:~ ['content-type' content-type]
Remove implicit +sell On each wakeup during send in light, we were spending about 7ms inside +sell. Replace that with an equivalent way of printing an integer to a tape. We now spend about half a ms on each outbound message.
2019-01-17 02:24:30 +03:00
['content-length' (crip (format-ud-as-integer p.data))]
More complete login flow
2018-09-27 02:18:40 +03:00
==
data=[~ data]
complete=%.y
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
==
More complete login flow
2018-09-27 02:18:40 +03:00
:: +authentication: per-event authentication as this Urbit's owner
::
:: Right now this hard codes the authentication page using the old +code
:: system, but in the future should be pluggable so we can use U2F or
:: WebAuthn or whatever is more secure than passwords.
::
++ authentication
|%
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
:: +handle-request: handles an http request for the login page
More complete login flow
2018-09-27 02:18:40 +03:00
::
++ handle-request
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
|= [secure=? host=(unit @t) =address [session-id=@uv =identity] =request:http]
More complete login flow
2018-09-27 02:18:40 +03:00
^- [(list move) server-state]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: parse the arguments out of request uri
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=+ request-line=(parse-request-line url.request)
=/ redirect (get-header:http 'redirect' args.request-line)
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
=/ with-eauth=(unit ?)
?: =(~ eauth-url:eauth) ~
`?=(^ (get-header:http 'eauth' args.request-line))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: if we received a simple get: redirect if logged in, otherwise
eyre: if logged in and accessing login page, redirect
2023-04-24 23:50:11 +03:00
:: show login page
More complete login flow
2018-09-27 02:18:40 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?: =('GET' method.request)
eyre: if logged in and accessing login page, redirect
2023-04-24 23:50:11 +03:00
?. (request-is-logged-in request)
%^ return-static-data-on-duct 200 'text/html'
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(login-page redirect our identity with-eauth %.n)
eyre: if logged in and accessing login page, redirect
2023-04-24 23:50:11 +03:00
=/ session-id (session-id-from-request request)
:: session-id should always be populated here since we are logged in
?~ session-id
%^ return-static-data-on-duct 200 'text/html'
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(login-page redirect our identity with-eauth %.n)
eyre: if logged in and accessing login page, redirect
2023-04-24 23:50:11 +03:00
=/ cookie-line=@t
(session-cookie-string u.session-id &)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=/ actual-redirect
eyre: if logged in and accessing login page, redirect
2023-04-24 23:50:11 +03:00
?~ redirect '/'
?:(=(u.redirect '') '/' u.redirect)
%- handle-response
:* %start
:- status-code=303
^= headers
:~ ['location' actual-redirect]
['set-cookie' cookie-line]
==
data=~
complete=%.y
==
More complete login flow
2018-09-27 02:18:40 +03:00
:: if we are not a post, return an error
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?. =('POST' method.request)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
%^ return-static-data-on-duct 405 'text/html'
(login-page ~ our identity with-eauth %.n)
More complete login flow
2018-09-27 02:18:40 +03:00
:: we are a post, and must process the body type as form data
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?~ body.request
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
%^ return-static-data-on-duct 400 'text/html'
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(login-page ~ our identity with-eauth %.n)
More complete login flow
2018-09-27 02:18:40 +03:00
::
=/ parsed=(unit (list [key=@t value=@t]))
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
(rush q.u.body.request yquy:de-purl:html)
More complete login flow
2018-09-27 02:18:40 +03:00
?~ parsed
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
%^ return-static-data-on-duct 400 'text/html'
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(login-page ~ our identity with-eauth %.n)
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: don't lose redirect upon failing login If we failed the password check, the login page served to us would never include any redirect details, even if they were there in the original request. Now we simply (attempt to) parse out the redirect field a little earlier.
2020-06-10 21:37:12 +03:00
=/ redirect=(unit @t) (get-header:http 'redirect' u.parsed)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?^ (get-header:http 'eauth' u.parsed)
?~ ship=(biff (get-header:http 'name' u.parsed) (cury slaw %p))
%^ return-static-data-on-duct 400 'text/html'
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
(login-page redirect our identity `& %.n)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::TODO redirect logic here and elsewhere is ugly
=/ redirect (fall redirect '')
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=/ base=(unit @t)
?~ host ~
`(cat 3 ?:(secure 'https://' 'http://') u.host)
(start:server:eauth u.ship base ?:(=(redirect '') '/' redirect))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
=. with-eauth (bind with-eauth |=(? |))
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?~ password=(get-header:http 'password' u.parsed)
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
%^ return-static-data-on-duct 400 'text/html'
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
(login-page redirect our identity with-eauth %.n)
More complete login flow
2018-09-27 02:18:40 +03:00
:: check that the password is correct
::
?. =(u.password code)
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
%^ return-static-data-on-duct 400 'text/html'
eyre: improve eauth login page ux We improve the styling on the login mode switching "tabs", ensure elements shared between the two modes are visually aligned, do loose input validation on the name field, and simply don't render the eauth option at all if the local ship does not yet have an +eauth-url.
2023-05-19 11:35:23 +03:00
(login-page redirect our identity with-eauth %.y)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: clean up the session they're changing out from
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=^ moz state
eyre: pass session-id+identity into auth handling This lets it also clean up guest sessions created just for the login request, and lets us display the current guest identity on the login page.
2023-05-09 16:10:14 +03:00
(close-session session-id |)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: initialize the new session
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=^ fex state (start-session %local)
:: associate the new session with the request that caused the login
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: if we don't do this here, +handle-response will include the old
:: session's cookie, confusing the client.
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=. connections.state
%+ ~(jab by connections.state) duct
|= o=outstanding-connection
o(session-id session.fex)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: store the hostname used for this login, later reuse it for eauth
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=? endpoint.auth.state ?=(^ host)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
%- (trace 2 |.("eauth: storing endpoint at {(trip u.host)}"))
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:+ user.endpoint.auth.state
`(cat 3 ?:(secure 'https://' 'http://') u.host)
now
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=; out=[moves=(list move) server-state]
out(moves [give-session-tokens :(weld moz moves.fex moves.out)])
::NOTE that we don't provide a 'set-cookie' header here.
:: +handle-response does that for us.
?~ redirect
(handle-response %start 204^~ ~ &)
eyre: upon login redirect parameter being empty, redirect to /
2020-03-10 03:16:43 +03:00
=/ actual-redirect ?:(=(u.redirect '') '/' u.redirect)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(handle-response %start 303^['location' actual-redirect]~ ~ &)
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
:: +handle-logout: handles an http request for logging out
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
++ handle-logout
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
|= [[session-id=@uv =identity] =request:http]
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
^- [(list move) server-state]
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
:: whatever we end up doing, we always respond with a redirect
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
::
=/ response=$>(%start http-event:http)
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
=/ redirect=(unit @t)
%+ get-header:http 'redirect'
args:(parse-request-line url.request)
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
:* %start
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
response-header=[303 ['location' (fall redirect '/~/login')]~]
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
data=~
complete=%.y
==
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
:: read options from the body
:: all: log out all sessions with this identity?
:: sid: which session do we log out? (defaults to requester's)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: hos: host to log out from, for eauth logins (sid signifies the nonce)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
=/ arg=header-list:http
?~ body.request ~
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(fall (rush q.u.body.request yquy:de-purl:html) ~)
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
=/ all=?
?=(^ (get-header:http 'all' arg))
=/ sid=(unit @uv)
?. ?=(%ours -.identity) `session-id
?~ sid=(get-header:http 'sid' arg) `session-id
:: if you provided the parameter, but it doesn't parse, we just
:: no-op. otherwise, a poorly-implemented frontend might result in
:: accidental log-outs, which would be very annoying.
::
(slaw %uv u.sid)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=/ hos=(unit @p)
?. ?=(%ours -.identity) ~
(biff (get-header:http 'host' arg) (cury slaw %p))
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
?~ sid
(handle-response response)
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
:: if this is an eauth remote logout, send the %shut
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=* auth auth.state
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?: ?=(^ hos)
=^ moz state (handle-response response)
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
:- [(send-plea:client:eauth u.hos %0 %shut u.sid) moz]
=/ book (~(gut by visiting.auth) u.hos *logbook)
=. qeu.book (~(put to qeu.book) u.sid)
=. visiting.auth (~(put by visiting.auth) u.hos book)
state
eyre: enable host to log out any other session Now that sessions with non-local identities can exist, the host/local identity should be empowered to forcefully log off any session it hosts. Additionally, we augment the logout logic with redirect functionality: it now respects the "redirect" query parameter in the same way the login page does. Still defaults to redirecting to the login page.
2023-05-06 00:30:53 +03:00
:: if the requester is logging themselves out, make them drop the cookie
::
=? headers.response-header.response =(u.sid session-id)
:_ headers.response-header.response
['set-cookie' (session-cookie-string session-id |)]
:: close the session as requested, then send the response
::
=^ moz1 state (close-session u.sid all)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=^ moz2 state (handle-response response)
[[give-session-tokens (weld moz1 moz2)] state]
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
:: +session-id-from-request: attempt to find a session cookie
More complete login flow
2018-09-27 02:18:40 +03:00
::
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
++ session-id-from-request
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
|= =request:http
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
^- (unit @uv)
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
:: are there cookies passed with this request?
::
:: TODO: In HTTP2, the client is allowed to put multiple 'Cookie'
:: headers.
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?~ cookie-header=(get-header:http 'cookie' header-list.request)
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
~
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
:: is the cookie line is valid?
::
?~ cookies=(rush u.cookie-header cock:de-purl:html)
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
~
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
:: is there an urbauth cookie?
::
eyre: forego <atom> in favor of (scow %aura atom) Pretty-printing is expensive, yet we do it whenever we construct the cookie string, at least once (but usually twice) per authenticated request. Here we call out the the specific to-tape functions we need, instead of relying on the pretty-printer for converting... tapes to tapes, among other things. The primary gains come from the cookie-related instances, we update the others mostly for good style. For the "receive request and immediately send response" case, that is processed synchronously within eyre (ie, client sends channel ack), speeds thing up by roughly 55%.
2020-11-04 03:02:11 +03:00
?~ urbauth=(get-header:http (crip "urbauth-{(scow %p our)}") u.cookies)
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
~
:: if it's formatted like a valid session cookie, produce it
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
::
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
`(unit @)`(rush u.urbauth ;~(pfix (jest '0v') viz:ag))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: +request-is-logged-in: checks to see if the request has non-guest id
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
::
++ request-is-logged-in
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= =request:http
^- ?
?~ session-id=(session-id-from-request request)
|
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?~ session=(~(get by sessions.auth.state) u.session-id)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|
&(!?=(%fake -.identity.u.session) (lte now expiry-time.u.session))
:: +request-is-authenticated: checks to see if the request is "us"
::
:: We are considered authenticated if this request has an urbauth
:: Cookie for the local identity that is not expired.
::
++ request-is-authenticated
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
|= =request:http
^- ?
:: does the request pass a session cookie?
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
::
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
?~ session-id=(session-id-from-request request)
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
%.n
:: is this a session that we know about?
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?~ session=(~(get by sessions.auth.state) `@uv`u.session-id)
check authentication state and pass it to the app
2018-09-27 21:16:59 +03:00
%.n
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: does this session have our id, and is it still valid?
::
&(?=(%ours -.identity.u.session) (lte now expiry-time.u.session))
:: +start-session: create a new session with %local or %guest identity
::
++ start-session
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
|= kind=?(%local %guest [%eauth who=@p])
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
^- [[session=@uv =identity moves=(list move)] server-state]
=; [key=@uv sid=identity]
:- :+ key sid
:: if no session existed previously, we must kick off the
:: session expiry timer
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?^ sessions.auth.state ~
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[duct %pass /sessions/expire %b %wait (add now session-timeout)]~
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=- state(sessions.auth -)
%+ ~(put by sessions.auth.state) key
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[sid (add now session-timeout) ~]
:: create a new session with a fake identity
::
=/ sik=@uv new-session-key
:- sik
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?: ?=(%local kind) [%ours ~]
?: ?=([%eauth @] kind) [%real who.kind]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:- %fake
:: pre-scramble our ship name into its displayed value, and
:: truncate it to be at most moon-length, so that we can overlay
eyre: make sure guest identity cannot be ours If there turned out to be some way for requesters to control the entropy, this might lead to privilege escalation on comets.
2023-05-09 16:31:47 +03:00
:: it onto the end of a comet name for visual consistency.
:: to prevent escalation, make sure the guest identity isn't ours.
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
eyre: make sure guest identity cannot be ours If there turned out to be some way for requesters to control the entropy, this might lead to privilege escalation on comets.
2023-05-09 16:31:47 +03:00
|-
=; nom=@p
?. =(our nom) nom
$(eny (shas %next-name eny))
eyre: refactor guest name generation Concatenating before we truncate, instead of truncating the entropy by itself, is slightly simpler. Because this slightly changes the naming algorithm, we must update the eyre tests to match.
2023-05-16 22:46:48 +03:00
%+ end 3^16
%^ cat 3
(end 3^8 (fein:ob our))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(~(raw og (shas %fake-name eny)) 128)
:: +session-for-request: get the session details for the request
::
:: creates a guest session if the request does not have a valid session.
:: there is no need to call +give-session-tokens after this, because
:: guest session do not make valid "auth session" tokens.
::
++ session-for-request
|= =request:http
^- [[session=@uv =identity moves=(list move)] server-state]
=* new (start-session %guest)
?~ sid=(session-id-from-request request)
new
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?~ ses=(~(get by sessions.auth.state) u.sid)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
new
?: (gth now expiry-time.u.ses)
new
[[u.sid identity.u.ses ~] state]
:: +close-session: delete a session and its associated channels
::
:: if :all is true, deletes all sessions that share the same identity.
:: if this closes an %ours session, the caller is responsible for
:: also calling +give-session-tokens afterwards.
::
++ close-session
|= [session-id=@uv all=?]
^- [(list move) server-state]
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?~ ses=(~(get by sessions.auth.state) session-id)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[~ state]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: delete the session(s) and find the associated ids & channels
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=^ [siz=(list @uv) channels=(list @t)] sessions.auth.state
=* sessions sessions.auth.state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: either delete just the specific session and its channels,
::
?. all
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:- [[session-id]~ ~(tap in channels.u.ses)]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(~(del by sessions) session-id)
:: or delete all sessions with the identity from :session-id
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
%+ roll ~(tap by sessions)
|= $: [sid=@uv s=session]
[[siz=(list @uv) caz=(list @t)] sez=(map @uv session)]
==
^+ [[siz caz] sez]
?. =(identity.s identity.u.ses)
:: identity doesn't match, so re-store this session
::
[[siz caz] (~(put by sez) sid s)]
:: identity matches, so register this session as closed
::
[[[sid siz] (weld caz ~(tap in channels.s))] sez]
:: close all affected channels and send their responses
::
=| moves1=(list move)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|- ^- (quip move server-state)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?^ channels
%- %+ trace 1
|.("{(trip i.channels)} discarding channel due to closed session")
=^ moz state
(discard-channel:by-channel i.channels |)
$(moves1 (weld moves1 moz), channels t.channels)
:: lastly, %real sessions require additional cleanup
::
?. ?=(%real -.identity.u.ses) [moves1 state]
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=^ moves2 visitors.auth.state
%+ roll ~(tap by visitors.auth.state)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
|= [[nonce=@uv visa=visitor] [moz=(list move) viz=(map @uv visitor)]]
?^ +.visa [moz (~(put by viz) nonce visa)]
:_ viz
%+ weld moz
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ duct.visa ~
[(send-boon:server:eauth(duct u.duct.visa) %0 %shut nonce)]~
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[(weld `(list move)`moves1 `(list move)`moves2) state]
More complete login flow
2018-09-27 02:18:40 +03:00
:: +code: returns the same as |code
::
++ code
^- @ta
%eyre: avoid +sloy when scrying for +code
2020-12-06 06:23:57 +03:00
=/ res=(unit (unit cage))
gall: implement local provenance
2023-05-22 16:12:09 +03:00
(rof ~ /eyre %j [our %code da+now] /(scot %p our))
%eyre: avoid +sloy when scrying for +code
2020-12-06 06:23:57 +03:00
(rsh 3 (scot %p ;;(@ q.q:(need (need res)))))
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
:: +session-cookie-string: compose session cookie
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
::
++ session-cookie-string
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
|= [session=@uv extend=?]
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
^- @t
%- crip
=; max-age=tape
eyre: revert inclusion of HttpOnly header for now
2023-02-13 21:58:59 +03:00
"urbauth-{(scow %p our)}={(scow %uv session)}; Path=/; Max-Age={max-age}"
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
%- format-ud-as-integer
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
?. extend 0
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
(div (msec:milly session-timeout) 1.000)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
++ eauth
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=* auth auth.state
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
|%
++ server
|%
:: +start: initiate an eauth login attempt for the :ship identity
::
++ start
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
|= [=ship base=(unit @t) last=@t]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- [(list move) server-state]
%- (trace 2 |.("eauth: starting eauth into {(scow %p ship)}"))
eyre: make sure eauth nonce is unique Similar to +new-session-key, we want to make sure that when we generate a new nonce, it isn't already in use.
2023-06-28 00:02:43 +03:00
=/ nonce=@uv
|-
=+ n=(~(raw og (shas %eauth-nonce eny)) 64)
?. (~(has by visitors.auth) n) n
$(eny (shas %try-again n))
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=/ visit=visitor [~ `[duct now] ship base last ~]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=. visitors.auth (~(put by visitors.auth) nonce visit)
:_ state
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: we delay serving an http response until we receive a scry %tune
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:~ (send-keen %keen ship nonce now)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(start-timeout /visitors/(scot %uv nonce))
==
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: +on-tune: receive a client-url remote scry result
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ on-tune
|= [ship=@p nonce=@uv url=@t]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- [(list move) server-state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- (trace 2 |.("eauth: %tune from {(scow %p ship)}"))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: guarantee the ship still controls the nonce
::
=/ visa=visitor (~(got by visitors.auth) nonce)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?> &(?=(^ +.visa) =(ship ship.visa))
:: redirect the visitor to their own confirmation page
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=. visitors.auth (~(put by visitors.auth) nonce visa(pend ~))
%- handle-response(duct http:(need pend.visa))
=; url=@t [%start 303^['location' url]~ ~ &]
%+ rap 3
:~ url
'?server=' (scot %p our)
'&nonce=' (scot %uv nonce)
==
:: +on-plea: receive an eauth network message from a client
::
++ on-plea
|= [=ship plea=eauth-plea]
^- [(list move) server-state]
%- (trace 2 |.("eauth: {(trip +<.plea)} from {(scow %p ship)}"))
=; res=[(list move) server-state]
=^ moz state res
[[[duct %give %done ~] moz] state]
?- +<.plea
%open
:: this attempt may or may not have been started in +start yet
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=/ visa=visitor
%+ ~(gut by visitors.auth) nonce.plea
[~ ~ ship ~ '/' ~]
?> ?=(^ +.visa)
?> =(ship ship.visa)
::NOTE that token might still be empty, in which case the http
:: client will probably signal an abort when they return
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=. duct.visa `duct
=. toke.visa token.plea
=. visitors.auth (~(put by visitors.auth) nonce.plea visa)
:: if the eauth attempt was started on our side, we may know the
:: specific base url the user used; make sure they go back there
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=/ url=@t
%- need
?~ base.visa eauth-url
eauth-url(user.endpoint.auth base.visa)
[[(send-boon %0 %okay nonce.plea url)]~ state]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%shut
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: the visitor wants the associated session gone
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ visa=(~(get by visitors.auth) nonce.plea) [~ state]
=. visitors.auth (~(del by visitors.auth) nonce.plea)
=? sessions.auth ?=(@ +.u.visa)
(~(del by sessions.auth) sesh.u.visa)
[[(send-boon %0 %shut nonce.plea)]~ state]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
:: +cancel: the client aborted the eauth attempt, so clean it up
::
++ cancel
|= [nonce=@uv last=@t]
^- [(list move) server-state]
:: if the eauth attempt doesn't exist, or it was already completed,
:: we cannot cancel it
::
?~ visa=(~(get by visitors.auth) nonce) [~ state]
?@ +.u.visa [~ state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: delete the attempt, and go back to the login page
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
%- (trace 2 |.("eauth: cancelling login"))
=. visitors.auth (~(del by visitors.auth) nonce)
=^ moz state
eyre: make sure we always url-encode the redirect Just for consistency, just in case.
2023-05-23 23:38:56 +03:00
=/ url=@t
%^ cat 3 '/~/login?eauth&redirect='
(crip (en-urlt:html (trip last)))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
(handle-response %start 303^['location' url]~ ~ &)
:_ state
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%+ weld moz
?~ duct.u.visa ~
[(send-boon(duct u.duct.u.visa) %0 %shut nonce)]~
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: +expire: host-side cancel an eauth attempt if it's still pending
::
++ expire
|= nonce=@uv
^- [(list move) server-state]
?~ visa=(~(get by visitors.auth) nonce)
[~ state]
?@ +.u.visa [~ state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- (trace 2 |.("eauth: expiring"))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=^ moz state
?~ pend.u.visa [~ state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- return-static-data-on-duct(duct http.u.pend.u.visa)
[503 'text/html' (eauth-error-page %server last.u.visa)]
=? moz ?=(^ pend.u.visa)
[(send-keen %yawn ship.u.visa nonce keen.u.pend.u.visa) moz]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=. visitors.auth (~(del by visitors.auth) nonce)
:_ state
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%+ weld moz
?~ duct.u.visa ~
[(send-boon(duct u.duct.u.visa) %0 %shut nonce)]~
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: +finalize: eauth attempt was approved: mint the client a new session
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: gives the http response on the current duct
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
++ finalize
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
|= [=plea=^duct nonce=@uv =ship last=@t]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- [(list move) server-state]
%- (trace 2 |.("eauth: finalizing login for {(scow %p ship)}"))
:: clean up the session they're changing out from,
:: mint the new session,
:: associate it with the nonce,
:: and the finalization request,
:: and send the visitor the cookie + final redirect
::
=^ moz1 state
(close-session session-id:(~(got by connections.state) duct) |)
=^ [sid=@uv * moz2=(list move)] state
(start-session %eauth ship)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=. visitors.auth
%+ ~(jab by visitors.auth) nonce
|=(v=visitor v(+ sid))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=. connections.state
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%+ ~(jab by connections.state) duct
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
|= o=outstanding-connection
o(session-id sid)
=^ moz3 state
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=; hed (handle-response %start 303^hed ~ &)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:~ ['location' last]
['set-cookie' (session-cookie-string sid &)]
==
[:(weld moz1 moz2 moz3) state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: +on-fail: we crashed or received an empty %tune, clean up
::
++ on-fail
|= [=ship nonce=@uv]
^- [(list move) server-state]
:: if the eauth attempt doesn't exist, or it was already completed,
:: we can no-op here
::
?~ visa=(~(get by visitors.auth) nonce) [~ state]
?@ +.u.visa [~ state]
:: delete the attempt, and go back to the login page
::
%- (trace 2 |.("eauth: failed login"))
=. visitors.auth (~(del by visitors.auth) nonce)
=^ moz state
?~ pend.u.visa [~ state]
%- return-static-data-on-duct(duct http.u.pend.u.visa)
[503 'text/html' (eauth-error-page %server last.u.visa)]
:_ state
%+ weld moz
?~ duct.u.visa ~
[(send-boon(duct u.duct.u.visa) %0 %shut nonce)]~
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
::TODO +on-request?
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ send-keen
|= [kind=?(%keen %yawn) =ship nonce=@uv =time]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- move
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- (trace 2 |.("eauth: %{(trip kind)} into {(scow %p ship)}"))
:: we round down the time to make it more likely to hit cache,
:: at the expense of not working if the endpoint changed within
:: the last hour.
::
=/ =wire /eauth/keen/(scot %p ship)/(scot %uv nonce)
=. time (sub time (mod time ~h1))
=/ =spar:ames [ship /e/x/(scot %da time)//eauth/url]
[duct %pass wire %a ?-(kind %keen keen+spar, %yawn yawn+spar)]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ send-boon
|= boon=eauth-boon
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- move
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- (trace 2 |.("eauth: sending {(trip +<.boon)}"))
[duct %give %boon boon]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
--
::
++ client
|%
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: +start: as the client, approve or abort an eauth attempt
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: assumes the duct is of an incoming eauth start/approve request
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ start
|= [host=ship nonce=@uv grant=?]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- [(list move) server-state]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=/ token=@uv (~(raw og (shas %eauth-token eny)) 128)
:: we always send an %open, because we need to redirect the user
:: back to the host. and we always set a timeout, because we may
:: not get a response quickly enough.
::
:- :~ (send-plea host %0 %open nonce ?:(grant `token ~))
(start-timeout /visiting/(scot %p host)/(scot %uv nonce))
==
:: make sure we aren't attempting with this nonce already,
:: then remember the secret so we can include it in the redirect
::
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book (~(gut by visiting.auth) host *logbook)
?< (~(has by map.book) nonce)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=. visiting.auth
%+ ~(put by visiting.auth) host
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
:- (~(put to qeu.book) nonce)
(~(put by map.book) nonce [`duct ?:(grant `token ~)])
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
state
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
:: +on-done: receive n/ack for plea we sent
::
++ on-done
|= [host=ship good=?]
^- [(list move) server-state]
%- %- trace
?: good
[2 |.("eauth: ack from {(scow %p host)}")]
[1 |.("eauth: nack from {(scow %p host)}")]
=/ book (~(gut by visiting.auth) host *logbook)
?~ ~(top to qeu.book)
%. [~ state]
(trace 0 |.("eauth: done on empty queue from {(scow %p host)}"))
=^ nonce=@uv qeu.book ~(get to qeu.book)
?: good
=. visiting.auth
?: =([~ ~] book)
(~(del by visiting.auth) host)
(~(put by visiting.auth) host book)
[~ state]
=/ port (~(get by map.book) nonce)
?~ port [~ state]
:: delete the attempt/session, serve response if needed
::
=. visiting.auth
=. map.book
(~(del by map.book) nonce)
?: =([~ ~] book)
(~(del by visiting.auth) host)
(~(put by visiting.auth) host book)
::
?@ u.port [~ state]
?~ pend.u.port [~ state]
%^ return-static-data-on-duct(duct u.pend.u.port) 503 'text/html'
(eauth-error-page ~)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: +on-boon: receive an eauth network response from a host
::
:: crashes on unexpected circumstances, in response to which we
:: should abort the eauth attempt
::
++ on-boon
|= [host=ship boon=eauth-boon]
^- [(list move) server-state]
%- (trace 2 |.("eauth: %{(trip +<.boon)} from {(scow %p host)}"))
?- +<.boon
%okay
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book (~(got by visiting.auth) host)
=/ port (~(got by map.book) nonce.boon)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?> ?=(^ port)
?> ?=(^ pend.port)
:: update the outgoing sessions map, deleting if we aborted
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
=. visiting.auth
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?^ toke.port
%+ ~(put by visiting.auth) host
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
:- qeu.book
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
::NOTE optimistic
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
(~(put by map.book) nonce.boon now)
=. map.book
(~(del by map.book) nonce.boon)
?: =([~ ~] book)
(~(del by visiting.auth) host)
(~(put by visiting.auth) host book)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: always serve a redirect, with either the token, or abort signal
::
=; url=@t
%- handle-response(duct u.pend.port)
[%start 303^['location' url]~ ~ &]
%+ rap 3
:* url.boon
'?nonce=' (scot %uv nonce.boon)
?~ toke.port ['&abort']~
~['&token=' (scot %uv u.toke.port)]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%shut
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: the host has deleted the corresponding session
::
=. visiting.auth
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book
(~(gut by visiting.auth) host *logbook)
=. map.book
(~(del by map.book) nonce.boon)
?: =([~ ~] book)
(~(del by visiting.auth) host)
(~(put by visiting.auth) host book)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[~ state]
==
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ expire
|= [host=ship nonce=@uv]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- [(list move) server-state]
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book (~(gut by visiting.auth) host *logbook)
=/ port (~(get by map.book) nonce)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: if the attempt was completed, we don't expire it
::
?~ port [~ state]
?@ u.port [~ state]
:: delete pending attempts, serve response if needed
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- %+ trace 1
|.("eauth: attempt into {(scow %p host)} expired")
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=. visiting.auth
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=. map.book
(~(del by map.book) nonce)
?: =([~ ~] book)
(~(del by visiting.auth) host)
(~(put by visiting.auth) host book)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ pend.u.port [~ state]
%^ return-static-data-on-duct(duct u.pend.u.port) 503 'text/html'
(eauth-error-page ~)
eyre: move incoming eauth expiry logic into +eauth +expiry:client:eauth, to be precise. This is a slightly cleaner factoring.
2023-05-23 23:37:05 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
++ send-plea
|= [=ship plea=eauth-plea]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
^- move
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
::NOTE no nonce in the wire, to avoid proliferating flows
=/ =wire /eauth/plea/(scot %p ship)
%- (trace 2 |.("eauth: {(trip +<.plea)} into {(scow %p ship)}"))
[[/eyre/eauth/synthetic]~ %pass wire %a %plea ship %e /eauth/0 plea]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
++ confirmation-page
|= [server=ship nonce=@uv]
^- octs
%- as-octs:mimes:html
%- crip
%- en-xml:html
=/ favicon %+
weld "<svg width='10' height='10' viewBox='0 0 10 10' xmlns='http://www.w3.org/2000/svg'>"
"<circle r='3.09' cx='5' cy='5' /></svg>"
;html
;head
;meta(charset "utf-8");
;meta(name "viewport", content "width=device-width, initial-scale=1, shrink-to-fit=no");
;link(rel "icon", type "image/svg+xml", href (weld "data:image/svg+xml;utf8," favicon));
;title:"Urbit"
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
;style:"{(trip auth-styling)}"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;style:'''
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
form {
border: 1px solid var(--black20);
border-radius: 4px;
padding: 1rem;
align-items: stretch;
font-size: 14px;
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
.red {
background: var(--black05) !important;
color: var(--black60) !important;
border: 1px solid var(--black60) !important;
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
code {
font-weight: bold;
font-family: "Source Code Pro", monospace;
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
button {
display: inline-block;
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
}
'''
==
;body
;form(action "/~/eauth", method "post")
eyre: include local id in the eauth confirm page We probably want something slightly fancier, like a banner or something, that also shows up on the login page (and perhaps other "system" pages), but for now this should suffice.
2023-06-16 22:22:37 +03:00
; Hello, {(scow %p our)}.
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
; You are trying to log in to:
;code:"{(scow %p server)}"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
;input(type "hidden", name "server", value (scow %p server));
;input(type "hidden", name "nonce", value (scow %uv nonce));
;button(type "submit", name "grant", value "grant"):"approve"
eyre: better styling for the eauth confirm page Brief prompt describing the login attempt's target, properly styled buttons. Pulls the CSS code for login pages out into its own arm for cleaner sharing.
2023-05-22 20:48:28 +03:00
;button(type "submit", name "reject", class "red"):"reject"
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
==
==
==
--
:: +on-request: http request to the /~/eauth endpoint
::
++ on-request
|= [[session-id=@uv =identity] =request:http]
^- [(list move) server-state]
eyre: only accept eauth approvals from ourselves Instead of accepting POST requests from anyone who asks.
2023-05-19 20:23:24 +03:00
:: we may need the requester to log in before proceeding
::
=* login
eyre: properly redirect unauthed eauth confirms We had naively changed the status code to a 403 "forbidden" response, which is technically correct, but the "Location" header isn't respected for that status code, leaving the user with a blank page instead of a login prompt.
2023-05-19 23:53:02 +03:00
=; url=@t (handle-response %start 303^['location' url]~ ~ &)
eyre: only accept eauth approvals from ourselves Instead of accepting POST requests from anyone who asks.
2023-05-19 20:23:24 +03:00
%^ cat 3 '/~/login?redirect='
(crip (en-urlt:html (trip url.request)))
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
:: or give them a generic, static error page in unexpected cases
::
=* error %^ return-static-data-on-duct 400 'text/html'
(eauth-error-page ~)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: GET requests either render the confirmation page,
:: or finalize an eauth flow
::
?: ?=(%'GET' method.request)
=/ args=(map @t @t) (malt args:(parse-request-line url.request))
=/ server=(unit @p) (biff (~(get by args) 'server') (cury slaw %p))
=/ nonce=(unit @uv) (biff (~(get by args) 'nonce') (cury slaw %uv))
=/ token=(unit @uv) (biff (~(get by args) 'token') (cury slaw %uv))
=/ abort=? (~(has by args) 'abort')
::
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
?~ nonce error
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
?^ server
:: request for confirmation page
::
eyre: only accept eauth approvals from ourselves Instead of accepting POST requests from anyone who asks.
2023-05-19 20:23:24 +03:00
?. ?=(%ours -.identity) login
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book (~(gut by visiting.auth) u.server *logbook)
=/ door (~(get by map.book) u.nonce)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ door
:: nonce not yet used, render the confirmation page as normal
::
%^ return-static-data-on-duct 200 'text/html'
(confirmation-page:client u.server u.nonce)
:: if we're still awaiting a redirect target, we choose to serve
:: this latest request instead
::
?@ u.door error
?~ pend.u.door error
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=. map.book (~(put by map.book) u.nonce u.door(pend `duct))
=. visiting.auth (~(put by visiting.auth) u.server book)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%- return-static-data-on-duct(duct u.pend.u.door)
[202 'text/plain' (as-octs:mimes:html 'continued elsewhere...')]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: important to provide an error response for unexpected states
::
=/ visa=(unit visitor) (~(get by visitors.auth) u.nonce)
?~ visa error
?@ +.u.visa error
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
=* error %^ return-static-data-on-duct 400 'text/html'
(eauth-error-page %server last.u.visa)
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: request for finalization, must either abort or provide a token
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: only accept eauth approvals from ourselves Instead of accepting POST requests from anyone who asks.
2023-05-19 20:23:24 +03:00
::NOTE yes, this means that unauthenticated clients can abort
:: any eauth attempt they know the nonce for, but that should
:: be pretty benign
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?: abort (cancel:^server u.nonce last.u.visa)
?~ token error
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
:: if this request provides a token, but the client didn't, complain
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ toke.u.visa error
:: verify the request
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
?. =(u.token u.toke.u.visa)
eyre: up priority on unexpected eauth traces These are more "warning" or "error" as opposed to informational like all the other ones at level 2.
2023-05-23 23:39:48 +03:00
%- (trace 1 |.("eauth: token mismatch"))
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
error
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ duct.u.visa error
(finalize:^server u.duct.u.visa u.nonce ship.u.visa last.u.visa)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
?. ?=(%'POST' method.request)
%^ return-static-data-on-duct 405 'text/html'
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
(eauth-error-page ~)
eyre: only accept eauth approvals from ourselves Instead of accepting POST requests from anyone who asks.
2023-05-19 20:23:24 +03:00
?. =(%ours -.identity) login
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
:: POST requests are always submissions of the confirmation page
::
=/ args=(map @t @t)
(malt (fall (rush q:(fall body.request *octs) yquy:de-purl:html) ~))
=/ server=(unit @p) (biff (~(get by args) 'server') (cury slaw %p))
=/ nonce=(unit @uv) (biff (~(get by args) 'nonce') (cury slaw %uv))
=/ grant=? =(`'grant' (~(get by args) 'grant'))
::
=* error %^ return-static-data-on-duct 400 'text/html'
eyre: factor +eauth-error-page out of event core This will make it easier to access for tests. The change to its interface is also nice: in pretty much all scenarios in which we call it, we already know whether we have redirect deets available to us, so just provide those as arguments instead of having the function re-derive.
2023-05-23 20:31:01 +03:00
(eauth-error-page ~)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?~ server error
?~ nonce error
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=/ book (~(gut by visiting.auth) u.server *logbook)
?: (~(has by map.book) u.nonce) error
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
(start:client u.server u.nonce grant)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
++ eauth-url
^- (unit @t)
=/ end=(unit @t) (clap user.endpoint.auth auth.endpoint.auth head)
tests: make eyre tests build & succeed again
2023-05-19 12:08:52 +03:00
?~ end ~
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
`(cat 3 u.end '/~/eauth')
::
++ start-timeout
|= =path
^- move
[duct %pass [%eauth %expire path] %b %wait (add now ~m5)]
--
More complete login flow
2018-09-27 02:18:40 +03:00
--
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: +channel: per-event handling of requests to the channel system
::
:: Eyre offers a remote interface to your Urbit through channels, which
Actually scry for the +code and inject the code deterministically into the tests
2019-03-18 23:48:00 +03:00
:: are persistent connections on the server which can be disconnected and
:: reconnected on the client.
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
++ by-channel
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: moves: the moves to be sent out at the end of this event, reversed
::
=| moves=(list move)
|%
:: +handle-request: handles an http request for the subscription system
::
++ handle-request
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [[session-id=@uv =identity] =address =request:http]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
^- [(list move) server-state]
:: parse out the path key the subscription is on
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
=+ request-line=(parse-request-line url.request)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
?. ?=([@t @t @t ~] site.request-line)
First test usage of the channel stuff from a real browser. Properly sends an error back.
2019-01-09 01:44:03 +03:00
:: url is not of the form '/~/channel/'
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
%^ return-static-data-on-duct 400 'text/html'
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(error-page 400 & url.request "malformed channel url")
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: channel-id: unique channel id parsed out of url
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
=+ channel-id=i.t.t.site.request-line
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?: =('PUT' method.request)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: PUT methods starts/modifies a channel, and returns a result immediately
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(on-put-request channel-id identity request)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?: =('GET' method.request)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(on-get-request channel-id [session-id identity] request)
Add support for POST delete channel requests using navigator.sendBeacon
2019-07-02 22:22:13 +03:00
?: =('POST' method.request)
:: POST methods are used solely for deleting channels
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(on-put-request channel-id identity request)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
cleaning code
2023-02-09 22:51:34 +03:00
((trace 0 |.("session not a put")) `state)
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
:: +on-cancel-request: cancels an ongoing subscription
::
:: One of our long lived sessions just got closed. We put the associated
:: session back into the waiting state.
::
++ on-cancel-request
^- [(list move) server-state]
:: lookup the session id by duct
::
message changed
2023-02-14 19:46:07 +03:00
%- (trace 1 |.("{<duct>} moving channel to waiting state"))
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
::
channel discarding messages added
2023-02-09 21:58:24 +03:00
?~ maybe-channel-id=(~(get by duct-to-key.channel-state.state) duct)
message changed
2023-02-14 19:46:07 +03:00
((trace 0 |.("{<duct>} no channel to move")) `state)
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
::
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
=/ maybe-session
(~(get by session.channel-state.state) u.maybe-channel-id)
channel discarding messages added
2023-02-09 21:58:24 +03:00
?~ maybe-session
((trace 1 |.("{<maybe-session>} session doesn't exist")) `state)
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
::
=/ heartbeat-cancel=(list move)
?~ heartbeat.u.maybe-session ~
:~ %^ cancel-heartbeat-move
u.maybe-channel-id
date.u.heartbeat.u.maybe-session
duct.u.heartbeat.u.maybe-session
==
::
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
=/ expiration-time=@da (add now channel-timeout)
::
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
:- %+ weld heartbeat-cancel
[(set-timeout-move u.maybe-channel-id expiration-time) moves]
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
%_ state
session.channel-state
%+ ~(jab by session.channel-state.state) u.maybe-channel-id
|= =channel
:: if we are canceling a known channel, it should have a listener
::
?> ?=([%| *] state.channel)
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
channel(state [%& [expiration-time duct]], heartbeat ~)
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
::
duct-to-key.channel-state
(~(del by duct-to-key.channel-state.state) duct)
==
:: +set-timeout-timer-for: sets a timeout timer on a channel
::
:: This creates a channel if it doesn't exist, cancels existing timers
:: if they're already set (we cannot have duplicate timers), and (if
:: necessary) moves channels from the listening state to the expiration
:: state.
::
++ update-timeout-timer-for
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [mode=?(%json %jam) =identity channel-id=@t]
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
^+ ..update-timeout-timer-for
:: when our callback should fire
::
=/ expiration-time=@da (add now channel-timeout)
:: if the channel doesn't exist, create it and set a timer
::
?~ maybe-channel=(~(get by session.channel-state.state) channel-id)
::
%_ ..update-timeout-timer-for
session.channel-state.state
%+ ~(put by session.channel-state.state) channel-id
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[mode identity [%& expiration-time duct] 0 now ~ ~ ~ ~]
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
::
moves
[(set-timeout-move channel-id expiration-time) moves]
==
:: if the channel has an active listener, we aren't setting any timers
::
?: ?=([%| *] state.u.maybe-channel)
..update-timeout-timer-for
:: we have a previous timer; cancel the old one and set the new one
::
%_ ..update-timeout-timer-for
session.channel-state.state
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
channel(state [%& [expiration-time duct]])
::
moves
:* (cancel-timeout-move channel-id p.state.u.maybe-channel)
(set-timeout-move channel-id expiration-time)
moves
==
==
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
++ set-heartbeat-move
|= [channel-id=@t heartbeat-time=@da]
^- move
:^ duct %pass /channel/heartbeat/[channel-id]
[%b %wait heartbeat-time]
::
++ cancel-heartbeat-move
|= [channel-id=@t heartbeat-time=@da =^duct]
^- move
:^ duct %pass /channel/heartbeat/[channel-id]
[%b %rest heartbeat-time]
::
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
++ set-timeout-move
|= [channel-id=@t expiration-time=@da]
^- move
[duct %pass /channel/timeout/[channel-id] %b %wait expiration-time]
::
++ cancel-timeout-move
|= [channel-id=@t expiration-time=@da =^duct]
^- move
:^ duct %pass /channel/timeout/[channel-id]
[%b %rest expiration-time]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: +on-get-request: handles a GET request
::
:: GET requests open a channel for the server to send events to the
:: client in text/event-stream format.
::
++ on-get-request
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [channel-id=@t [session-id=@uv =identity] =request:http]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
^- [(list move) server-state]
:: if there's no channel-id, we must 404
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
::TODO but arm description says otherwise?
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
?~ maybe-channel=(~(get by session.channel-state.state) channel-id)
%^ return-static-data-on-duct 404 'text/html'
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(error-page 404 | url.request ~)
:: find the channel creator's identity, make sure it matches
::
?. =(identity identity.u.maybe-channel)
%^ return-static-data-on-duct 403 'text/html'
(error-page 403 | url.request ~)
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
:: find the requested "mode" and make sure it doesn't conflict
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
::
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
=/ mode=?(%json %jam)
(find-channel-mode %'GET' header-list.request)
?. =(mode mode.u.maybe-channel)
%^ return-static-data-on-duct 406 'text/html'
=; msg=tape (error-page 406 %.y url.request msg)
"channel already established in {(trip mode.u.maybe-channel)} mode"
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: when opening an event-stream, we must cancel our timeout timer
eyre: replace channel upon new GET request As SSE are unidirectional, the client always realises that the connection has failed faster than the server does. Hence, resuming a subscription is useless, because channels can only be bound to one duct at a time. Now, instead of failing a request for a channel that is already bound to a duct, we replace the duct and continue normally.
2021-06-24 03:24:55 +03:00
:: if there's no duct already bound. Else, kill the old request
:: and replace it
::
=^ cancel-moves state
eyre: address mark review
2021-06-25 01:28:06 +03:00
?. ?=([%| *] state.u.maybe-channel)
eyre: replace channel upon new GET request As SSE are unidirectional, the client always realises that the connection has failed faster than the server does. Hence, resuming a subscription is useless, because channels can only be bound to one duct at a time. Now, instead of failing a request for a channel that is already bound to a duct, we replace the duct and continue normally.
2021-06-24 03:24:55 +03:00
:_ state
(cancel-timeout-move channel-id p.state.u.maybe-channel)^~
eyre: address mark review
2021-06-25 01:28:06 +03:00
=/ cancel-heartbeat
eyre: replace channel upon new GET request As SSE are unidirectional, the client always realises that the connection has failed faster than the server does. Hence, resuming a subscription is useless, because channels can only be bound to one duct at a time. Now, instead of failing a request for a channel that is already bound to a duct, we replace the duct and continue normally.
2021-06-24 03:24:55 +03:00
?~ heartbeat.u.maybe-channel ~
:_ ~
eyre: address mark review
2021-06-25 01:28:06 +03:00
%+ cancel-heartbeat-move channel-id
eyre: replace channel upon new GET request As SSE are unidirectional, the client always realises that the connection has failed faster than the server does. Hence, resuming a subscription is useless, because channels can only be bound to one duct at a time. Now, instead of failing a request for a channel that is already bound to a duct, we replace the duct and continue normally.
2021-06-24 03:24:55 +03:00
[date duct]:u.heartbeat.u.maybe-channel
=- [(weld cancel-heartbeat -<) ->]
eyre: address mark review
2021-06-25 01:28:06 +03:00
(handle-response(duct p.state.u.maybe-channel) [%cancel ~])
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:: the request may include a 'Last-Event-Id' header
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
=/ maybe-last-event-id=(unit @ud)
eyre: look for lowercase last-event-id header Eyre always gets passed request headers in lowercase, so we should search for the lowercased version of the header. Arguably `+get-header` should lowercase keys before comparing them, but that's a more serious behavioral change.
2022-08-30 17:44:11 +03:00
?~ maybe-raw-header=(get-header:http 'last-event-id' header-list.request)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
~
(rush u.maybe-raw-header dum:ag)
:: flush events older than the passed in 'Last-Event-ID'
::
=? state ?=(^ maybe-last-event-id)
(acknowledge-events channel-id u.maybe-last-event-id)
:: combine the remaining queued events to send to the client
::
=/ event-replay=wall
%- zing
%- flop
=/ queue events.u.maybe-channel
=| events=(list wall)
|-
^+ events
?: =(~ queue)
events
=^ head queue ~(get to queue)
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
=, p.head
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
::NOTE these will only fail if the mark and/or json types changed,
:: since conversion failure also gets caught during first receive.
:: we can't do anything about this, so consider it unsupported.
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=/ said
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
(channel-event-to-tape u.maybe-channel request-id channel-event)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
?~ said $
$(events [(event-tape-to-wall id +.u.said) events])
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: send the start event to the client
::
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
=^ http-moves state
%- handle-response
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:* %start
:- 200
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:~ ['content-type' 'text/event-stream']
['cache-control' 'no-cache']
['connection' 'keep-alive']
==
(wall-to-octs event-replay)
complete=%.n
==
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
:: associate this duct with this session key
::
=. duct-to-key.channel-state.state
(~(put by duct-to-key.channel-state.state) duct channel-id)
eyre, zuse: expire channels with their sessions Associates channels with the authentication sessions that opened them, and deletes the channel when its associated session expires. Also updates the debug dashboard to display channel counts per session.
2020-06-04 23:06:13 +03:00
:: associate this channel with the session cookie
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=. sessions.auth.state
%+ ~(jab by sessions.auth.state)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
session-id
eyre, zuse: expire channels with their sessions Associates channels with the authentication sessions that opened them, and deletes the channel when its associated session expires. Also updates the debug dashboard to display channel counts per session.
2020-06-04 23:06:13 +03:00
|= =session
session(channels (~(put in channels.session) channel-id))
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
:: initialize sse heartbeat
::
=/ heartbeat-time=@da (add now ~s20)
=/ heartbeat (set-heartbeat-move channel-id heartbeat-time)
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
:: record the mode & duct for future output,
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
:: and record heartbeat-time for possible future cancel
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
=. session.channel-state.state
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
%_ channel
mode mode
state [%| duct]
heartbeat (some [heartbeat-time duct])
==
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
eyre: replace channel upon new GET request As SSE are unidirectional, the client always realises that the connection has failed faster than the server does. Hence, resuming a subscription is useless, because channels can only be bound to one duct at a time. Now, instead of failing a request for a channel that is already bound to a duct, we replace the duct and continue normally.
2021-06-24 03:24:55 +03:00
[[heartbeat :(weld http-moves cancel-moves moves)] state]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: +acknowledge-events: removes events before :last-event-id on :channel-id
::
++ acknowledge-events
|= [channel-id=@t last-event-id=@u]
^- server-state
%_ state
session.channel-state
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
^+ channel
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
=^ acked events.channel
(prune-events events.channel last-event-id)
=. unacked.channel
(subtract-acked-events acked unacked.channel)
channel(last-ack now)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
==
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: +on-put-request: handles a PUT request
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: PUT requests send commands from the client to the server. We receive
:: a set of commands in JSON format in the body of the message.
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
++ on-put-request
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [channel-id=@t =identity =request:http]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
^- [(list move) server-state]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: if the channel already exists, and is not of this identity, 403
::
:: the creation case happens in the +update-timeout-timer-for below
::
?: ?~ c=(~(get by session.channel-state.state) channel-id) |
!=(identity identity.u.c)
%^ return-static-data-on-duct 403 'text/html'
(error-page 403 | url.request ~)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: error when there's no body
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?~ body.request
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%^ return-static-data-on-duct 400 'text/html'
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
(error-page 400 %.y url.request "no put body")
eyre: deduce channel mode from headers, not url
2022-11-28 20:30:04 +03:00
::
=/ mode=?(%json %jam)
(find-channel-mode %'PUT' header-list.request)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
:: if we cannot parse requests from the body, give an error
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=/ maybe-requests=(each (list channel-request) @t)
(parse-channel-request mode u.body.request)
?: ?=(%| -.maybe-requests)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%^ return-static-data-on-duct 400 'text/html'
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
(error-page 400 & url.request (trip p.maybe-requests))
Get things compiling, and refactor auth in tests.
2018-11-16 02:27:49 +03:00
:: while weird, the request list could be empty
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
?: =(~ p.maybe-requests)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
%^ return-static-data-on-duct 400 'text/html'
Centralize error pages in one gate and support 403 on unauthenticated.
2019-03-21 23:58:37 +03:00
(error-page 400 %.y url.request "empty list of actions")
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: check for the existence of the channel-id
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
:: if we have no session, create a new one set to expire in
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
:: :channel-timeout from now. if we have one which has a timer, update
:: that timer.
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=. ..on-put-request (update-timeout-timer-for mode identity channel-id)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: for each request, execute the action passed in
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=+ requests=p.maybe-requests
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
:: gall-moves: put moves here first so we can flop for ordering
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
:: errors: if we accumulate any, discard the gall-moves and revert
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
::
=| gall-moves=(list move)
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
=| errors=(map @ud @t)
=/ og-state state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=/ from=ship
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?+(-.identity who.identity %ours our)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
|-
Send the right moves in response to a PUT request.
2018-11-17 01:30:23 +03:00
::
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
?~ requests
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
?: =(~ errors)
:: everything succeeded, mark the request as completed
::
=^ http-moves state
%- handle-response
:* %start
[status-code=204 headers=~]
data=~
complete=%.y
==
::
[:(weld (flop gall-moves) http-moves moves) state]
:: some things went wrong. revert all operations & give 400
Send the right moves in response to a PUT request.
2018-11-17 01:30:23 +03:00
::
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
%- (trace 1 |.("{<channel-id>} reverting due to errors"))
=. state og-state
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
=^ http-moves state
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
%^ return-static-data-on-duct 400 'text/html'
%- as-octs:mimes:html
%+ rap 3
%+ turn (sort ~(tap by errors) dor)
|= [id=@ud er=@t]
(rap 3 (crip (a-co:co id)) ': ' er '<br/>' ~)
[(weld http-moves moves) state]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
?- -.i.requests
%ack
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
:: client acknowledges that they have received up to event-id
::
%_ $
state (acknowledge-events channel-id event-id.i.requests)
requests t.requests
==
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
?(%poke %poke-json)
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
=, i.requests
::
?. |(=(from our) =(ship our))
=+ [request-id 'non-local operation']
$(errors (~(put by errors) -), requests t.requests)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
=. gall-moves
gall: implement local provenance
2023-05-22 16:12:09 +03:00
=/ =wire /channel/poke/[channel-id]/(scot %ud request-id.i.requests)
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
:_ gall-moves
Send the right moves in response to a PUT request.
2018-11-17 01:30:23 +03:00
^- move
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
/channel/poke/[channel-id]/(scot %ud request-id)
:^ from ship app
^- task:agent:gall
:+ %poke-as mark
?- -.i.requests
%poke [%noun !>(noun)]
%poke-json [%json !>(json)]
mall: convert lanaguage-server
2019-11-05 10:42:59 +03:00
==
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
$(requests t.requests)
::
eyre: fix tests
2019-11-14 06:38:13 +03:00
%subscribe
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
=, i.requests
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
::
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
?. |(=(from our) =(ship our))
=+ [request-id 'non-local operation']
$(errors (~(put by errors) -), requests t.requests)
::
::TODO could error if the subscription is a duplicate
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
=. gall-moves
:_ gall-moves
^- move
changed messages
2023-02-09 20:55:08 +03:00
%- (trace 1 |.("subscribing to {<app>} on {<path>}"))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
(subscription-wire channel-id request-id from ship app)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[from ship app %watch path]
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
::
=. session.channel-state.state
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
eyre: simplify channel subscription storage Instead of storing by "channel wire", store by request-id instead. The channel wire was just the channel-id, request-id, and some cruft.
2020-10-19 01:48:18 +03:00
=- channel(subscriptions -)
%+ ~(put by subscriptions.channel)
request-id
[ship app path duct]
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
::
$(requests t.requests)
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: fix tests
2019-11-14 06:38:13 +03:00
%unsubscribe
eyre: simplify channel subscription storage Instead of storing by "channel wire", store by request-id instead. The channel wire was just the channel-id, request-id, and some cruft.
2020-10-19 01:48:18 +03:00
=, i.requests
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
::
eyre: give 400 for invalid channel requests We previously had no mechanism for giving error responses, if a client submitted an invalid request into a channel. Guest access makes this important, because guests cannot interact with remote ships. Attempting to do so will cause a gall crash. Here, we add error handling logic to channel request processing. We catch the invalid cases described above and invalidate the entire batch of channel requests if they occur. We make sure to drop the moves and revert the state we changed, and give a 400 to the client that informally describes the problem(s).
2023-05-05 23:08:18 +03:00
?. |(=(from our) =(ship our))
=+ [request-id 'non-local operation']
$(errors (~(put by errors) -), requests t.requests)
::
Remove got by on unvalidated %unsubscribe action input
2019-07-17 20:51:56 +03:00
=/ usession (~(get by session.channel-state.state) channel-id)
?~ usession
$(requests t.requests)
=/ subscriptions subscriptions:u.usession
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
::
eyre: simplify channel subscription storage Instead of storing by "channel wire", store by request-id instead. The channel wire was just the channel-id, request-id, and some cruft.
2020-10-19 01:48:18 +03:00
?~ maybe-subscription=(~(get by subscriptions) subscription-id)
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
:: the client sent us a weird request referring to a subscription
:: which isn't active.
::
style fixes
2023-02-09 01:03:02 +03:00
%. $(requests t.requests)
cleaning code
2023-02-09 22:51:34 +03:00
=* msg=tape "{(trip channel-id)} {<subscription-id>}"
cleaning
2023-02-09 23:06:06 +03:00
(trace 0 |.("missing subscription in unsubscribe {msg}"))
Having the client unsubscribe should actually unsubscribe on the server
2019-03-15 21:25:12 +03:00
::
=. gall-moves
:_ gall-moves
^- move
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
=, u.maybe-subscription
cleaning up message rankings
2023-02-09 22:22:50 +03:00
%- (trace 1 |.("leaving subscription to {<app>}"))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
(subscription-wire channel-id subscription-id from ship app)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[from ship app %leave ~]
Having the client unsubscribe should actually unsubscribe on the server
2019-03-15 21:25:12 +03:00
::
=. session.channel-state.state
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
%_ channel
subscriptions (~(del by subscriptions.channel) subscription-id)
unacked (~(del by unacked.channel) subscription-id)
==
Having the client unsubscribe should actually unsubscribe on the server
2019-03-15 21:25:12 +03:00
::
$(requests t.requests)
Added ability to quit channel from rver
2019-06-14 00:53:04 +03:00
::
%delete
channel discarding messages added
2023-02-09 21:58:24 +03:00
%- (trace 1 |.("{<channel-id>} discarding due to %delete PUT"))
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
=^ moves state
(discard-channel channel-id |)
Added ability to quit channel from rver
2019-06-14 00:53:04 +03:00
=. gall-moves
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
(weld gall-moves moves)
Added ability to quit channel from rver
2019-06-14 00:53:04 +03:00
$(requests t.requests)
::
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
==
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
:: +on-gall-response: sanity-check a gall response, send as event
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
++ on-gall-response
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
|= [channel-id=@t request-id=@ud extra=wire =sign:agent:gall]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
^- [(list move) server-state]
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
:: if the channel doesn't exist, we should clean up subscriptions
::
:: this is a band-aid solution. you really want eyre to have cleaned
:: these up on-channel-delete in the first place.
:: until the source of that bug is discovered though, we keep this
:: in place to ensure a slightly tidier home.
::
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
?. ?& !(~(has by session.channel-state.state) channel-id)
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
?=(?(%fact %watch-ack) -.sign)
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
?=([@ @ *] extra)
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
==
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
(emit-event channel-id request-id sign)
=/ =ship (slav %p i.extra)
=* app=term i.t.extra
cleaning up message rankings
2023-02-09 22:22:50 +03:00
=* msg=tape "{(trip channel-id)} {(trip app)}"
changed messages
2023-02-09 20:55:08 +03:00
%- (trace 0 |.("removing watch for non-existent channel {msg}"))
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
:_ state
:_ ~
^- move
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
=/ as=^ship
?+ t.t.extra ~|([%strange-wire extra] !!)
~ our :: old-style wire
[@ ~] (slav %p i.t.t.extra)
==
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
(subscription-wire channel-id request-id as ship app)
[as ship app %leave ~]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:: +emit-event: records an event occurred, possibly sending to client
::
:: When an event occurs, we need to record it, even if we immediately
:: send it to a connected browser so in case of disconnection, we can
:: resend it.
::
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:: This function is responsible for taking the event sign and converting
:: it into a text/event-stream. The :sign then may get sent, and is
:: stored for later resending until acknowledged by the client.
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
++ emit-event
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
|= [channel-id=@t request-id=@ud =sign:agent:gall]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
^- [(list move) server-state]
::
Made cross-ship collections posting work Made collections json endpoint work
2019-03-29 20:44:37 +03:00
=/ channel=(unit channel)
(~(get by session.channel-state.state) channel-id)
?~ channel
eyre: turn sigpam into flog This error is mostly harmless, but it does indicate we aren't cleaning up our subscriptions properly. This lets you silence with |knob. fixes #2088
2019-12-14 11:43:04 +03:00
:_ state :_ ~
[duct %pass /flog %d %flog %crud %eyre-no-channel >id=channel-id< ~]
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
:: it's possible that this is a sign emitted directly alongside a fact
eyre: ignore facts directly after clog When an application would send multiple facts during a single event, it was possible for the first fact to trigger a clog, removing the subscription and sending a quit, but then the second fact still getting sent out at normal. Here, we drop any facts for subscriptions we don't have registered in state, which should only happen in the described case.
2020-10-24 12:45:21 +03:00
:: that triggered a clog & closed the subscription. in that case, just
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
:: drop the sign.
:: poke-acks are not paired with subscriptions, so we can process them
:: regardless.
eyre: ignore facts directly after clog When an application would send multiple facts during a single event, it was possible for the first fact to trigger a clog, removing the subscription and sending a quit, but then the second fact still getting sent out at normal. Here, we drop any facts for subscriptions we don't have registered in state, which should only happen in the described case.
2020-10-24 12:45:21 +03:00
::
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
?: ?& !?=(%poke-ack -.sign)
eyre: ignore facts directly after clog When an application would send multiple facts during a single event, it was possible for the first fact to trigger a clog, removing the subscription and sending a quit, but then the second fact still getting sent out at normal. Here, we drop any facts for subscriptions we don't have registered in state, which should only happen in the described case.
2020-10-24 12:45:21 +03:00
!(~(has by subscriptions.u.channel) request-id)
==
[~ state]
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
:: attempt to convert the sign to json.
:: if conversion succeeds, we *can* send it. if the client is actually
:: connected, we *will* send it immediately.
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
=/ maybe-channel-event=(unit channel-event)
(sign-to-channel-event sign u.channel request-id)
?~ maybe-channel-event [~ state]
=/ =channel-event u.maybe-channel-event
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=/ said=(unit (quip move tape))
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
(channel-event-to-tape u.channel request-id channel-event)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=? moves ?=(^ said)
(weld moves -.u.said)
=* sending &(?=([%| *] state.u.channel) ?=(^ said))
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
::
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
=/ next-id next-id.u.channel
:: if we can send it, store the event as unacked
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=? events.u.channel ?=(^ said)
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
%- ~(put to events.u.channel)
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
[next-id request-id channel-event]
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
:: if it makes sense to do so, send the event to the client
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
=? moves sending
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
^- (list move)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
:_ moves
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
::NOTE assertions in this block because =* is flimsy
?> ?=([%| *] state.u.channel)
Made cross-ship collections posting work Made collections json endpoint work
2019-03-29 20:44:37 +03:00
:+ p.state.u.channel %give
zuse: lift moves out of +able
2020-12-08 03:47:06 +03:00
^- gift
Separate interaces into %http-server and %http-client A repeating patern while developing was confusion over whether an operation was inbound or outbound. By putting this into the gift and tasks, we can avoid this: an [%http-server %request ...] is not an [%http-client %request ...]. (This requires corresponding vere changes since it changes the unix/vane interface.)
2019-02-06 01:05:06 +03:00
:* %response %continue
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
^= data
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
%- wall-to-octs
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
(event-tape-to-wall next-id +:(need said))
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
complete=%.n
==
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=? next-id ?=(^ said) +(next-id)
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:: update channel's unacked counts, find out if clogged
::
=^ clogged unacked.u.channel
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
:: only apply clog logic to facts.
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
:: and of course don't count events we can't send as unacked.
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
::
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
?: ?| !?=(%fact -.sign)
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
?=(~ said)
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
==
[| unacked.u.channel]
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
=/ num=@ud
(~(gut by unacked.u.channel) request-id 0)
:_ (~(put by unacked.u.channel) request-id +(num))
?& (gte num clog-threshold)
(lth (add last-ack.u.channel clog-timeout) now)
==
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
:: if we're clogged, or we ran into an event we can't serialize,
:: kill this gall subscription.
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
::
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
=* msg=tape "on {(trip channel-id)} for {(scow %ud request-id)}"
fixed kick messages
2023-02-08 21:47:43 +03:00
=/ kicking=?
?: clogged
cleaning
2023-02-09 23:06:06 +03:00
((trace 0 |.("clogged {msg}")) &)
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
?. ?=(~ said) |
requested changes fixed
2023-02-16 18:02:34 +03:00
((trace 0 |.("can't serialize event, kicking {msg}")) &)
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
=? moves kicking
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:_ moves
eyre: clog exclusively for %facts Eyre's clog logic was a tad inconsistent about "only facts" vs "not poke-acks". This makes it consistently say "only facts" when it comes to clog-related logic. Yes, in theory this means %watch-acks and %kicks can build up endlessly, but those should take up negligible space compared to %facts. Should fix any oddball cases of crashes here that #3835 didn't already catch.
2020-11-11 00:06:28 +03:00
::NOTE this shouldn't crash because we
:: - never fail to serialize subscriptionless signs (%poke-ack),
:: - only clog on %facts, which have a subscription associated,
:: - and already checked whether we still have that subscription.
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
=+ (~(got by subscriptions.u.channel) request-id)
cleaning up message rankings
2023-02-09 22:22:50 +03:00
%- (trace 1 |.("leaving subscription to {<app>}"))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
(subscription-wire channel-id request-id identity.u.channel ship app)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[identity.u.channel ship app %leave ~]
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
:: update channel state to reflect the %kick
::
=? u.channel kicking
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
%_ u.channel
subscriptions (~(del by subscriptions.u.channel) request-id)
unacked (~(del by unacked.u.channel) request-id)
events %- ~(put to events.u.channel)
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
:+ next-id
request-id
(need (sign-to-channel-event [%kick ~] u.channel request-id))
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
==
:: if a client is connected, send the kick event to them
::
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
=? moves &(kicking ?=([%| *] state.u.channel))
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:_ moves
:+ p.state.u.channel %give
zuse: lift moves out of +able
2020-12-08 03:47:06 +03:00
^- gift
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:* %response %continue
::
^= data
%- wall-to-octs
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
%+ event-tape-to-wall next-id
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
+:(need (channel-event-to-tape u.channel request-id %kick ~))
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
::
complete=%.n
==
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
=? next-id kicking +(next-id)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
::
eyre: produce moves in correct order Because storing in reverse order means producing in reverse reverse order. The tests didn't catch this because they, too, were infected with the "reverse moves" meme.
2020-10-24 02:48:51 +03:00
:- (flop moves)
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
%_ state
Channel cancelation works now.
2018-11-22 00:37:26 +03:00
session.channel-state
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
%+ ~(put by session.channel-state.state) channel-id
eyre: kick subscriptions if fact conversion fails This matches the behavior that gall uses for %watch-as subscriptions, which eyre was using previously.
2020-10-19 20:17:58 +03:00
u.channel(next-id next-id)
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
==
eyre: kick busy subscriptions if client not acking In order to curb event queue growth when a client for whatever reason isn't acking the events we send out, we implement a mechanism for detecting such "clogging", and proactively kick subscriptions which are adding too many events to the queue. If the client hasn't sent an ack for ~s30, any subscription that accrues more than 50 unacked %facts gets closed to prevent further buildup. Upon reconnecting, the client will see %kick for the relevant subscriptions and can open a new subscription as appropriate. Includes a simple test for this behavior, and updates /app/dbug to be able to display the newly tracked statistics.
2020-10-19 16:56:05 +03:00
:: +sign-to-channel-event: strip the vase from a sign:agent:gall
::
++ sign-to-channel-event
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
|= [=sign:agent:gall =channel request-id=@ud]
^- (unit channel-event)
?. ?=(%fact -.sign) `sign
?~ desk=(app-to-desk channel request-id) ~
:- ~
[%fact u.desk [p q.q]:cage.sign]
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
:: +app-to-desk
::
++ app-to-desk
|= [=channel request-id=@ud]
^- (unit desk)
=/ sub (~(get by subscriptions.channel) request-id)
?~ sub
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
((trace 0 |.("no subscription for request-id {(scow %ud request-id)}")) ~)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
=/ des=(unit (unit cage))
gall: implement local provenance
2023-05-22 16:12:09 +03:00
(rof ~ /eyre %gd [our app.u.sub da+now] /$)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
?. ?=([~ ~ *] des)
cleaning code
2023-02-09 22:51:34 +03:00
((trace 0 |.("no desk for app {<app.u.sub>}")) ~)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
`!<(=desk q.u.u.des)
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
:: +channel-event-to-tape: render channel-event from request-id in specified mode
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
::
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
++ channel-event-to-tape
|= [=channel request-id=@ud =channel-event]
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
^- (unit (quip move tape))
?- mode.channel
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
%json %+ bind (channel-event-to-json channel request-id channel-event)
json: remove deprecated JSON parser calls
2023-06-30 22:25:19 +03:00
|=((quip move json) [+<- (trip (en:json:html +<+))])
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
%jam =- `[~ (scow %uw (jam -))]
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
[request-id channel-event]
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
==
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
:: +channel-event-to-json: render channel event as json channel event
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
::
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
++ channel-event-to-json
~% %eyre-channel-event-to-json ..part ~
|= [=channel request-id=@ud event=channel-event]
eyre: replace +slam with +slym for a speedup
2021-05-20 22:31:28 +03:00
^- (unit (quip move json))
eyre: convert facts to json manually By doing a %watch instead of %watch-as %json for channel subscriptions, we can hopefully make better use of noun deduplication, when storing events in a channel's event queue until they get acked.
2020-10-18 17:31:35 +03:00
:: for facts, we try to convert the result to json
::
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
=/ [from=(unit [=desk =mark]) jsyn=(unit sign:agent:gall)]
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
?. ?=(%fact -.event) [~ `event]
?: ?=(%json mark.event)
?~ jsin=((soft json) noun.event)
%. [~ ~]
(slog leaf+"eyre: dropping fake json for {(scow %ud request-id)}" ~)
[~ `[%fact %json !>(u.jsin)]]
eyre: convert facts to json manually By doing a %watch instead of %watch-as %json for channel subscriptions, we can hopefully make better use of noun deduplication, when storing events in a channel's event queue until they get acked.
2020-10-18 17:31:35 +03:00
:: find and use tube from fact mark to json
::
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
::
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
=* have=mark mark.event
eyre: use slam and statically typed conversion
2021-05-20 21:03:04 +03:00
=/ convert=(unit vase)
eyre: use static mark conversions
2021-05-20 20:11:45 +03:00
=/ cag=(unit (unit cage))
gall: implement local provenance
2023-05-22 16:12:09 +03:00
(rof ~ /eyre %cf [our desk.event da+now] /[have]/json)
eyre: use static mark conversions
2021-05-20 20:11:45 +03:00
?. ?=([~ ~ *] cag) ~
eyre: use slam and statically typed conversion
2021-05-20 21:03:04 +03:00
`q.u.u.cag
eyre: use static mark conversions
2021-05-20 20:11:45 +03:00
?~ convert
cleaning
2023-02-09 22:56:50 +03:00
((trace 0 |.("no convert from {(trip have)} to json")) [~ ~])
~| "conversion failed from {(trip have)} to json"
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
[`[desk.event have] `[%fact %json (slym u.convert noun.event)]]
eyre: replace +slam with +slym for a speedup
2021-05-20 22:31:28 +03:00
?~ jsyn ~
eyre: convert facts to json manually By doing a %watch instead of %watch-as %json for channel subscriptions, we can hopefully make better use of noun deduplication, when storing events in a channel's event queue until they get acked.
2020-10-18 17:31:35 +03:00
%- some
eyre: replace +slam with +slym for a speedup
2021-05-20 22:31:28 +03:00
:- ?~ from ~
eyre: send warp to warm %c cache for any mark that gets used
2021-05-19 23:40:32 +03:00
:_ ~
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
:^ duct %pass /conversion-cache/[mark.u.from]
[%c %warp our desk.u.from `[%sing %f da+now /[mark.u.from]/json]]
eyre: replace +slam with +slym for a speedup
2021-05-20 22:31:28 +03:00
=* sign u.jsyn
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
=, enjs:format
%- pairs
^- (list [@t json])
:- ['id' (numb request-id)]
?- -.sign
%poke-ack
:~ ['response' [%s 'poke']]
::
?~ p.sign
['ok' [%s 'ok']]
['err' (wall (render-tang-to-wall 100 u.p.sign))]
==
::
%fact
eyre: include mark of fact in channel json This change greatly improves the ergonomics of working with channel JSON in statically typed languages, as the polymorphism is moved out of the actual diff and into the event framing.
2021-12-02 01:48:57 +03:00
:+ ['response' [%s 'diff']]
:- 'json'
~| [%unexpected-fact-mark p.cage.sign]
?> =(%json p.cage.sign)
!<(json q.cage.sign)
::
?~ from ~
eyre: address mark review, update pill
2021-12-02 17:06:42 +03:00
['mark' [%s mark.u.from]]~
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
::
%kick
['response' [%s 'quit']]~
::
%watch-ack
:~ ['response' [%s 'subscribe']]
::
?~ p.sign
['ok' [%s 'ok']]
['err' (wall (render-tang-to-wall 100 u.p.sign))]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
==
==
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
::
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
++ event-tape-to-wall
~% %eyre-tape-to-wall ..part ~
|= [event-id=@ud =tape]
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
^- wall
:~ (weld "id: " (format-ud-as-integer event-id))
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
(weld "data: " tape)
eyre: store unacked events unserialized Store the gall events from channel subscriptions as (vaseless) signs, instead of serialized events. This should be smaller in memory, and makes it more likely for noun deduplication to happen. The cost is needing to reserialize upon channel reconnect, but this is the less common case, and we don't expect it to be particularly slow.
2020-10-18 12:18:29 +03:00
""
==
::
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
++ on-channel-heartbeat
|= channel-id=@t
^- [(list move) server-state]
::
=/ res
%- handle-response
:* %continue
eyre: send comments as heartbeats, not empty events The previous behaviour, in addition to not being conformant with the spec, breaks correct reconnect behaviour. See: https://html.spec.whatwg.org/multipage/server-sent-events.html#event-stream-interpretation
2021-06-30 04:45:50 +03:00
data=(some (as-octs:mimes:html ':\0a'))
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
complete=%.n
==
=/ http-moves -.res
=/ new-state +.res
=/ heartbeat-time=@da (add now ~s20)
:_ %_ new-state
session.channel-state
%+ ~(jab by session.channel-state.state) channel-id
|= =channel
channel(heartbeat (some [heartbeat-time duct]))
==
(snoc http-moves (set-heartbeat-move channel-id heartbeat-time))
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
:: +discard-channel: remove a channel from state
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
:: cleans up state, timers, and gall subscriptions of the channel
::
++ discard-channel
|= [channel-id=@t expired=?]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
^- [(list move) server-state]
::
Remove got by on unvalidated %unsubscribe action input
2019-07-17 20:51:56 +03:00
=/ usession=(unit channel)
(~(get by session.channel-state.state) channel-id)
?~ usession
[~ state]
=/ session=channel u.usession
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
::
Get things compiling, and refactor auth in tests.
2018-11-16 02:27:49 +03:00
:_ %_ state
session.channel-state
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
(~(del by session.channel-state.state) channel-id)
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
::
duct-to-key.channel-state
?. ?=(%| -.state.session) duct-to-key.channel-state.state
(~(del by duct-to-key.channel-state.state) p.state.session)
Get things compiling, and refactor auth in tests.
2018-11-16 02:27:49 +03:00
==
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
=/ heartbeat-cancel=(list move)
?~ heartbeat.session ~
:~ %^ cancel-heartbeat-move
channel-id
date.u.heartbeat.session
duct.u.heartbeat.session
==
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
=/ expire-cancel=(list move)
?: expired ~
?. ?=(%& -.state.session) ~
=, p.state.session
[(cancel-timeout-move channel-id date duct)]~
eyre: fix missing cancel-heartbeat-move cases
2019-10-10 14:33:11 +03:00
%+ weld heartbeat-cancel
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
%+ weld expire-cancel
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:: produce a list of moves which cancels every gall subscription
::
Make %light handle multiple subscriptions on the same path. Some applications make multiple subscriptions to the same app on the same path. Support this by changing the subscription interface to return a numeric reference which needs to be passed in during the explicit unsubscribe, and ensure that we send per-subscription instead of per-path unsubscribe commands to Gall.
2019-03-27 01:52:32 +03:00
%+ turn ~(tap by subscriptions.session)
eyre: simplify channel subscription storage Instead of storing by "channel wire", store by request-id instead. The channel wire was just the channel-id, request-id, and some cruft.
2020-10-19 01:48:18 +03:00
|= [request-id=@ud ship=@p app=term =path duc=^duct]
Get things compiling, and refactor auth in tests.
2018-11-16 02:27:49 +03:00
^- move
cleaning up message rankings
2023-02-09 22:22:50 +03:00
%- (trace 1 |.("{<channel-id>} leaving subscription to {<app>}"))
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%+ deal-as
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
(subscription-wire channel-id request-id identity.session ship app)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[identity.session ship app %leave ~]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
--
A %coup failure from gall should return a 500 to the client.
2019-03-19 23:38:18 +03:00
:: +handle-gall-error: a call to +poke-http-response resulted in a %coup
::
++ handle-gall-error
|= =tang
^- [(list move) server-state]
::
eyre: no-op on agent-error when missing connection state
2023-05-04 01:25:10 +03:00
?~ connection-state=(~(get by connections.state) duct)
%. `state
(trace 0 |.("{<duct>} error on invalid outstanding connection"))
=* connection u.connection-state
eyre: remove eyre-id from eyre's state
2019-11-13 12:38:18 +03:00
=/ moves-1=(list move)
eyre: cancel subscriptions more aggressively
2019-11-13 12:21:14 +03:00
?. ?=(%app -.action.connection)
~
:_ ~
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=, connection
%- (trace 1 |.("leaving subscription to {<app.action>}"))
(deal-as /watch-response/[eyre-id] identity our app.action %leave ~)
A %coup failure from gall should return a 500 to the client.
2019-03-19 23:38:18 +03:00
::
eyre: cancel subscriptions more aggressively
2019-11-13 12:21:14 +03:00
=^ moves-2 state
%^ return-static-data-on-duct 500 'text/html'
::
%- internal-server-error :*
authenticated.inbound-request.connection
url.request.inbound-request.connection
tang
==
eyre: remove eyre-id from eyre's state
2019-11-13 12:38:18 +03:00
[(weld moves-1 moves-2) state]
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
:: +handle-response: check a response for correctness and send to earth
Send responses.
2018-09-24 21:48:19 +03:00
::
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
:: All outbound responses including %http-server generated responses need to go
Don't use ~(nap to ...). I must be using it wrong; it produces wrong answer sometimes.
2019-01-12 01:15:17 +03:00
:: through this interface because we want to have one centralized place
:: where we perform logging and state cleanup for connections that we're
:: done with.
::
Send responses.
2018-09-24 21:48:19 +03:00
++ handle-response
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
|= =http-event:http
Send responses.
2018-09-24 21:48:19 +03:00
^- [(list move) server-state]
:: verify that this is a valid response on the duct
::
?~ connection-state=(~(get by connections.state) duct)
cleaning
2023-02-09 22:56:50 +03:00
((trace 0 |.("{<duct>} invalid outstanding connection")) `state)
Send responses.
2018-09-24 21:48:19 +03:00
::
|^ ^- [(list move) server-state]
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?- -.http-event
Send responses.
2018-09-24 21:48:19 +03:00
::
%start
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?^ response-header.u.connection-state
cleaning
2023-02-09 23:06:06 +03:00
((trace 0 |.("{<duct>} error multiple start")) error-connection)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: extend the request's session's + cookie's life
Send responses.
2018-09-24 21:48:19 +03:00
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=^ response-header sessions.auth.state
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
=, authentication
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=* session-id session-id.u.connection-state
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=* sessions sessions.auth.state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=* inbound inbound-request.u.connection-state
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
?. (~(has by sessions) session-id)
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
:: if the session has expired since the request was opened,
:: tough luck, we don't create/revive sessions here
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[response-header.http-event sessions]
:_ %+ ~(jab by sessions) session-id
eyre, zuse: expire channels with their sessions Associates channels with the authentication sessions that opened them, and deletes the channel when its associated session expires. Also updates the debug dashboard to display channel counts per session.
2020-06-04 23:06:13 +03:00
|= =session
session(expiry-time (add now session-timeout))
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
=- response-header.http-event(headers -)
%^ set-header:http 'set-cookie'
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
(session-cookie-string session-id &)
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
headers.response-header.http-event
Send responses.
2018-09-24 21:48:19 +03:00
::
eyre: remove redundant connection retrieval
2023-05-04 01:25:48 +03:00
=* connection u.connection-state
::
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
:: if the request was a simple cors request from an approved origin
:: append the necessary cors headers to the response
::
=/ origin=(unit origin)
%+ get-header:http 'origin'
header-list.request.inbound-request.connection
=? headers.response-header
?& ?=(^ origin)
(~(has in approved.cors-registry.state) u.origin)
==
%^ set-header:http 'Access-Control-Allow-Origin' u.origin
%^ set-header:http 'Access-Control-Allow-Credentials' 'true'
headers.response-header
::
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
=. response-header.http-event response-header
Send responses.
2018-09-24 21:48:19 +03:00
=. connections.state
eyre: optimizes responses, removes redundant connection state updates
2023-05-04 01:39:19 +03:00
?: complete.http-event
:: XX optimize by not requiring +put:by in +request
::
(~(del by connections.state) duct)
::
changed messages
2023-02-09 20:55:08 +03:00
%- (trace 2 |.("{<duct>} start"))
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
%+ ~(put by connections.state) duct
eyre: remove redundant connection retrieval
2023-05-04 01:25:48 +03:00
%= connection
eyre: extend session duration on-use When sending a response to an authenticated request, update the session to last for +session-timeout again, and send an updated cookie to match. Assuming the user makes an actual HTTP request at least once a week, this will make sure they don't get logged out automatically. Simply keeping a channel open, unfortunately, doesn't count.
2020-05-30 03:29:20 +03:00
response-header `response-header
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
bytes-sent ?~(data.http-event 0 p.u.data.http-event)
Send responses.
2018-09-24 21:48:19 +03:00
==
::
pass-response
::
%continue
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?~ response-header.u.connection-state
style fixes
2023-02-09 01:03:02 +03:00
%. error-connection
cleaning
2023-02-09 23:06:06 +03:00
(trace 0 |.("{<duct>} error continue without start"))
Send responses.
2018-09-24 21:48:19 +03:00
::
=. connections.state
eyre: optimizes responses, removes redundant connection state updates
2023-05-04 01:39:19 +03:00
?: complete.http-event
%- (trace 2 |.("{<duct>} completed"))
(~(del by connections.state) duct)
::
%- (trace 2 |.("{<duct>} continuing"))
?~ data.http-event
connections.state
::
%+ ~(put by connections.state) duct
=* size p.u.data.http-event
=* conn u.connection-state
conn(bytes-sent (add size bytes-sent.conn))
Send responses.
2018-09-24 21:48:19 +03:00
::
pass-response
::
%cancel
:: todo: log this differently from an ise.
::
error connections tuned
2023-02-09 21:06:02 +03:00
((trace 1 |.("cancel http event")) error-connection)
Send responses.
2018-09-24 21:48:19 +03:00
==
::
++ pass-response
^- [(list move) server-state]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
[[duct %give %response http-event]~ state]
Send responses.
2018-09-24 21:48:19 +03:00
::
++ error-connection
:: todo: log application error
::
:: remove all outstanding state for this connection
::
=. connections.state
(~(del by connections.state) duct)
:: respond to outside with %error
::
^- [(list move) server-state]
eyre: cancel subscriptions more aggressively
2019-11-13 12:21:14 +03:00
:_ state
:- [duct %give %response %cancel ~]
?. ?=(%app -.action.u.connection-state)
~
:_ ~
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=, u.connection-state
cleaning up message rankings
2023-02-09 22:22:50 +03:00
%- %+ trace 1
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|.("leaving subscription to {<app.action>}")
(deal-as /watch-response/[eyre-id] identity our app.action %leave ~)
Send responses.
2018-09-24 21:48:19 +03:00
--
eyre: add cache
2023-03-25 07:18:25 +03:00
:: +set-response: remember (or update) a cache mapping
::
++ set-response
|= [url=@t entry=(unit cache-entry)]
^- [(list move) server-state]
=/ aeon ?^(prev=(~(get by cache.state) url) +(aeon.u.prev) 1)
=. cache.state (~(put by cache.state) url [aeon entry])
:_ state
[outgoing-duct.state %give %grow /cache/(scot %ud aeon)/(scot %t url)]~
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: +add-binding: conditionally add a pairing between binding and action
::
:: Adds =binding =action if there is no conflicting bindings.
::
++ add-binding
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
|= [=binding =action]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
^- [(list move) server-state]
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
=^ success bindings.state
eyre: prevent binding in reserved namespaces Disallows registering bindings (through %connect and %serve) that would capture traffic on paths starting with /~ (Eyre's) or /~_~ (runtime's, as of cc389c5). Note that we don't touch +insert-binding, which is used by Eyre internally to set up bindings in its own namespace.
2020-10-06 17:50:49 +03:00
:: prevent binding in reserved namespaces
::
?: ?| ?=([%'~' *] path.binding) :: eyre
?=([%'~_~' *] path.binding) :: runtime
==
[| bindings.state]
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
[& (insert-binding [binding duct action] bindings.state)]
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
:_ state
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
[duct %give %bound & binding]~
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: +remove-binding: removes a binding if it exists and is owned by this duct
::
++ remove-binding
|= =binding
::
^- server-state
%_ state
bindings
%+ skip bindings.state
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
|= [item-binding=^binding item-duct=^duct =action]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
^- ?
&(=(item-binding binding) =(item-duct duct))
==
:: +get-action-for-binding: finds an action for an incoming web request
::
++ get-action-for-binding
|= [raw-host=(unit @t) url=@t]
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
^- [=action suburl=@t]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: process :raw-host
::
:: If we are missing a 'Host:' header, if that header is a raw IP
:: address, or if the 'Host:' header refers to [our].urbit.org, we want
Change host matching so ~ will match any inbound.
2019-06-04 00:34:01 +03:00
:: to return ~ which means we're unidentified and will match against any
:: wildcard matching.
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
:: Otherwise, return the site given.
::
=/ host=(unit @t)
?~ raw-host
~
We now have an application path rendering
2018-10-03 21:36:45 +03:00
:: Parse the raw-host so that we can ignore ports, usernames, etc.
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
Fix url parser and add tests.
2018-10-04 00:05:36 +03:00
=+ parsed=(rush u.raw-host simplified-url-parser)
?~ parsed
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
~
We now have an application path rendering
2018-10-03 21:36:45 +03:00
:: if the url is a raw IP, assume default site.
::
Fix url parser and add tests.
2018-10-04 00:05:36 +03:00
?: ?=([%ip *] -.u.parsed)
~
:: if the url is "localhost", assume default site.
::
?: =([%site 'localhost'] -.u.parsed)
~
:: render our as a tape, and cut off the sig in front.
::
=/ with-sig=tape (scow %p our)
?> ?=(^ with-sig)
?: =(u.raw-host (crip t.with-sig))
:: [our].urbit.org is the default site
::
~
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
raw-host
:: url is the raw thing passed over the 'Request-Line'.
::
More complete login flow
2018-09-27 02:18:40 +03:00
:: todo: this is really input validation, and we should return a 500 to
:: the client.
::
=/ request-line (parse-request-line url)
=/ parsed-url=(list @t) site.request-line
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
=? parsed-url ?=([%'~' %channel-jam *] parsed-url)
parsed-url(i.t %channel)
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
=/ bindings bindings.state
|-
::
?~ bindings
eyre: find sub-path for binding In addition to producing the action bound for a given request, now also produces the subset of the request url that comes _after_ the path at which the binding has been established. Will allow some bindings to more easily dispatch off the relevant part of the url.
2020-06-11 02:42:21 +03:00
[[%four-oh-four ~] url]
::
?. (host-matches site.binding.i.bindings raw-host)
$(bindings t.bindings)
?~ suffix=(find-suffix path.binding.i.bindings parsed-url)
$(bindings t.bindings)
::
:- action.i.bindings
%^ cat 3
%+ roll
^- (list @t)
(join '/' (flop ['' u.suffix]))
(cury cat 3)
?~ ext.request-line ''
(cat 3 '.' u.ext.request-line)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: +give-session-tokens: send valid local session tokens to unix
eyre: send valid auth tokens to the runtime Whenever a session gets created or removed, send the set of valid auth tokens to the runtime, so that it may use them in determining whether incoming requests are authenticated or not.
2022-08-24 01:34:08 +03:00
::
++ give-session-tokens
^- move
:- outgoing-duct.state
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:+ %give %sessions
%- sy
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
%+ murn ~(tap by sessions.auth.state)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [sid=@uv session]
?. ?=(%ours -.identity) ~
(some (scot %uv sid))
:: +new-session-key
::
++ new-session-key
|- ^- @uv
=/ candidate=@uv (~(raw og (shas %session-key eny)) 128)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
?. (~(has by sessions.auth.state) candidate)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
candidate
$(eny (shas %try-again candidate))
::
++ deal-as
|= [=wire identity=$@(@p identity) =ship =dude:gall =task:agent:gall]
^- move
=/ from=@p
?@ identity identity
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?+(-.identity who.identity %ours our)
Merge branch 'next/kelvin/412' into tinnus/local-provenance
2023-06-07 11:38:05 +03:00
[duct %pass wire %g %deal [from ship /eyre] dude task]
trace moved into +per-server-event
2023-02-08 22:43:13 +03:00
::
++ trace
|= [pri=@ print=(trap tape)]
veb to verb
2023-02-08 23:19:14 +03:00
?: (lth verb.state pri) same
trace moved into +per-server-event
2023-02-08 22:43:13 +03:00
(slog leaf+"eyre: {(print)}" ~)
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
--
Change host matching so ~ will match any inbound.
2019-06-04 00:34:01 +03:00
::
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
++ forwarded-params
eyre: respect "forwarded" header from localhost For request transparency, HTTP proxies may set the Forwarded header to specify who the original requester is. For requests from localhost only, we make Eyre respect the Forwarded header, and adjust the handled ip address accordingly. Note that we do not support X-Forwarded or other non-standard variants. The header remains in the request, so server applications can handle them as desired. Fixes #2723.
2020-05-31 18:43:35 +03:00
|= =header-list:http
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
^- (unit (list (map @t @t)))
%+ biff
eyre: respect "forwarded" header from localhost For request transparency, HTTP proxies may set the Forwarded header to specify who the original requester is. For requests from localhost only, we make Eyre respect the Forwarded header, and adjust the handled ip address accordingly. Note that we do not support X-Forwarded or other non-standard variants. The header remains in the request, so server applications can handle them as desired. Fixes #2723.
2020-05-31 18:43:35 +03:00
(get-header:http 'forwarded' header-list)
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
unpack-header:http
::
++ forwarded-for
|= forwards=(list (map @t @t))
^- (unit address)
?. ?=(^ forwards) ~
=* forward i.forwards
?~ for=(~(get by forward) 'for') ~
::NOTE per rfc7239, non-ip values are also valid. they're not useful
:: for the general case, so we ignore them here. if needed,
:: request handlers are free to inspect the headers themselves.
eyre: respect "forwarded" header from localhost For request transparency, HTTP proxies may set the Forwarded header to specify who the original requester is. For requests from localhost only, we make Eyre respect the Forwarded header, and adjust the handled ip address accordingly. Note that we do not support X-Forwarded or other non-standard variants. The header remains in the request, so server applications can handle them as desired. Fixes #2723.
2020-05-31 18:43:35 +03:00
::
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
%+ rush u.for
;~ sfix
hoon: update glyph names (continued)
2020-11-15 08:08:52 +03:00
;~(pose (stag %ipv4 ip4) (stag %ipv6 (ifix [sel ser] ip6)))
eyre: respect protocol from Forwarded header If the Forwarded header specifies the original connection is secure, update the flag to reflect that, regardless of whether the connection directly to the urbit was made securely.
2020-10-29 16:24:24 +03:00
;~(pose ;~(pfix col dim:ag) (easy ~))
==
::
++ forwarded-secure
|= forwards=(list (map @t @t))
^- (unit ?)
?. ?=(^ forwards) ~
=* forward i.forwards
?~ proto=(~(get by forward) 'proto') ~
?+ u.proto ~
%http `|
%https `&
==
Change host matching so ~ will match any inbound.
2019-06-04 00:34:01 +03:00
::
++ parse-request-line
|= url=@t
^- [[ext=(unit @ta) site=(list @t)] args=(list [key=@t value=@t])]
(fall (rush url ;~(plug apat:de-purl:html yque:de-purl:html)) [[~ ~] ~])
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
:: +insert-binding: add a new binding, replacing any existing at its path
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
::
++ insert-binding
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
|= $: new=[=binding =duct =action]
bindings=(list [=binding =duct =action])
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
==
^+ bindings
?~ bindings [new]~
=* bid binding.i.bindings
:: replace already bound paths
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
::
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
?: =([site path]:bid [site path]:binding.new)
~> %slog.[0 leaf+"eyre: replacing existing binding at {<`path`path.bid>}"]
[new t.bindings]
:: if new comes before bid, prepend it.
:: otherwise, continue our search.
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
::
eyre: allow overwriting existing bindings Previously, if trying to bind to an endpoint that was already bound to, eyre would reject it. This doesn't play very nicely in a softdist world where uninstalled apps might not get a chance to clean up, and apps might re-bind simply for being re-installed. Here we change eyre to overwrite an existing binding if it conflicts with the new one to be added.
2021-09-24 23:54:24 +03:00
=; new-before-bid=?
?: new-before-bid [new bindings]
[i.bindings $(bindings t.bindings)]
?: =(site.binding.new site.bid)
eyre: bind most specific endpoint first This sticks to the old behavior, which was briefly lost in recent changes.
2021-09-25 16:44:31 +03:00
(aor path.bid path.binding.new)
(aor (fall site.bid '') (fall site.binding.new ''))
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
::
++ channel-wire
|= [channel-id=@t request-id=@ud]
^- wire
/channel/subscription/[channel-id]/(scot %ud request-id)
::
++ subscription-wire
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
|= [channel-id=@t request-id=@ud as=$@(@p identity) =ship app=term]
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
^- wire
eyre: avoid +got'ing a channel that doesn't exist +on-gall-response might detect the symptom of a bug, where we are getting a %fact for a channel that has since been deleted. (Meaning that subscription should have been cleaned up, and we shouldn't have received the %fact.) We want to issue a %leave, but need to take care to do so with the same identity that the subscription was opened on. Previously, we would forcefully get the identity from the non-existent channel, resulting in a crash. Now, we encode the identity into the wire instead, so that we may retrieve it from there, even when the channel is long gone.
2023-08-10 12:33:08 +03:00
=/ from=@p
?@ as as
?+(-.as who.as %ours our)
%+ weld (channel-wire channel-id request-id)
::NOTE including the originating identity is important for the band-aid
:: solution currently present in +on-gall-response, where we may
:: need to issue a %leave after we've forgotten the identity with
:: which the subscription was opened.
/(scot %p ship)/[app]/(scot %p from)
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
--
:: end the =~
::
. ==
:: begin with a default +axle as a blank slate
::
=| ax=axle
:: a vane is activated with current date, entropy, and a namespace function
::
arvo: updates vane interface
2020-12-06 11:38:37 +03:00
|= [now=@da eny=@uvJ rof=roof]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
:: allow jets to be registered within this core
::
arvo: removes +is and all references to it
2020-12-05 07:32:17 +03:00
~% %http-server ..part ~
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
|%
++ call
clay, eyre: add profiling hints
2021-03-28 10:47:37 +03:00
~/ %eyre-call
zuse: lift moves out of +able
2020-12-08 03:47:06 +03:00
|= [=duct dud=(unit goof) wrapped-task=(hobo task)]
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
^- [(list move) _http-server-gate]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
zuse: lift moves out of +able
2020-12-08 03:47:06 +03:00
=/ task=task ((harden task) wrapped-task)
vane: downcast all error notifications to %crud
2020-02-24 22:09:37 +03:00
::
eyre: when a %request causes a crud, serve 500 Previously, if an incoming request caused a crash, we would just drop it on the floor. We should at least have the decency to serve the client a quick 500 and let them get on with their day. We make sure not to touch state here. The connection is guaranteed-fresh because of the task's semantics, and we're handling it in-line in one go. Notably we only give a simple "crud!" for the body, instead of the full error trace. We don't know whether the request is authenticated or not (and who knows if checking was the cause of the crash!), and the crud might leak sensitive details about the ship it occurred on. For the owner, the trace still gets printed into the terminal.
2023-05-04 18:33:37 +03:00
:: XX handle more error notifications
vane: downcast all error notifications to %crud
2020-02-24 22:09:37 +03:00
::
zuse: remove %crud from vane-task
2020-12-08 05:01:48 +03:00
?^ dud
eyre: when a %request causes a crud, serve 500 Previously, if an incoming request caused a crash, we would just drop it on the floor. We should at least have the decency to serve the client a quick 500 and let them get on with their day. We make sure not to touch state here. The connection is guaranteed-fresh because of the task's semantics, and we're handling it in-line in one go. Notably we only give a simple "crud!" for the body, instead of the full error trace. We don't know whether the request is authenticated or not (and who knows if checking was the cause of the crash!), and the crud might leak sensitive details about the ship it occurred on. For the owner, the trace still gets printed into the terminal.
2023-05-04 18:33:37 +03:00
:_ http-server-gate
:: always print the error trace
::
:- [duct %slip %d %flog %crud [-.task tang.u.dud]]
^- (list move)
:: if a request caused the crash, respond with a 500
::
?. ?=(?(%request %request-local) -.task) ~
^~
=/ data (as-octs:mimes:html 'crud!')
=/ head
:~ ['content-type' 'text/html']
['content-length' (crip (a-co:co p.data))]
==
[duct %give %response %start 500^head `data &]~
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:: %init: tells us what our ship name is
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?: ?=(%init -.task)
More complete login flow
2018-09-27 02:18:40 +03:00
:: initial value for the login handler
::
=. bindings.server-state.ax
eyre: bind most specific endpoint first This sticks to the old behavior, which was briefly lost in recent changes.
2021-09-25 16:44:31 +03:00
=- (roll - insert-binding)
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
^- (list [binding ^duct action])
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
:~ [[~ /~/login] duct [%authentication ~]]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[[~ /~/eauth] duct [%eauth ~]]
eyre: provide logout endpoint Set up, by default, on /~/logout. Sending a POST request to this expires the current session and redirects to the login page. If the "all" key is set in the request body, expires all open sessions.
2020-06-03 02:40:32 +03:00
[[~ /~/logout] duct [%logout ~]]
WIP: Commented out wip to get something wich +solid s
2018-11-15 21:27:10 +03:00
[[~ /~/channel] duct [%channel ~]]
eyre: support %gx scries Exposes a scry endpoint. Any requests made to the /app/scry.mark url under the endpoint will scry into %app using a %gx scry, at the /scry/noun path, and attempt to convert the scry result into the %mark, before converting that into the %mime mark, and sending that as an http response.
2020-06-11 02:45:05 +03:00
[[~ /~/scry] duct [%scry ~]]
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
[[~ /~/name] duct [%name ~]]
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
[[~ /~/host] duct [%host ~]]
More complete login flow
2018-09-27 02:18:40 +03:00
==
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[~ http-server-gate]
arvo: wires up %trim memory-pressure event stubs
2019-09-27 23:00:37 +03:00
:: %trim: in response to memory pressure
::
eyre: close channels in response to memory pressure
2019-10-01 21:34:22 +03:00
:: Cancel all inactive channels
:: XX cancel active too if =(0 trim-priority) ?
::
arvo: wires up %trim memory-pressure event stubs
2019-09-27 23:00:37 +03:00
?: ?=(%trim -.task)
eyre: fix for %trim bug - addendum Broader, more direct solution.
2022-07-09 03:10:41 +03:00
=* event-args [[eny duct now rof] server-state.ax]
eyre: close channels in response to memory pressure
2019-10-01 21:34:22 +03:00
=* by-channel by-channel:(per-server-event event-args)
=* channel-state channel-state.server-state.ax
::
=/ inactive=(list @t)
=/ full=(set @t) ~(key by session.channel-state)
=/ live=(set @t)
(~(gas in *(set @t)) ~(val by duct-to-key.channel-state))
~(tap in (~(dif in full) live))
::
?: =(~ inactive)
[~ http-server-gate]
::
=/ len=tape (scow %ud (lent inactive))
~> %slog.[0 leaf+"eyre: trim: closing {len} inactive channels"]
::
=| moves=(list (list move))
|- ^- [(list move) _http-server-gate]
=* channel-id i.inactive
?~ inactive
[(zing (flop moves)) http-server-gate]
:: discard channel state, and cancel any active gall subscriptions
::
eyre: refactor %delete to reuse timeout logic Turns +on-channel-timeout into +discard-channel, which cleans up the entirety of the channel, based on its current state. This allows us to simplify the %delete channel request into a simple function call.
2020-06-04 18:12:35 +03:00
=^ mov server-state.ax (discard-channel:by-channel channel-id |)
eyre: close channels in response to memory pressure
2019-10-01 21:34:22 +03:00
$(moves [mov moves], inactive t.inactive)
::
cleans up +task comments in %lient and %rver
2019-03-13 23:35:14 +03:00
:: %vega: notifies us of a completed kernel upgrade
Bootable and Dojo can issue +http requests. But no vere support yet.
2019-02-12 01:41:50 +03:00
::
?: ?=(%vega -.task)
[~ http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:: %born: new unix process
cleans up +task comments in %lient and %rver
2019-03-13 23:35:14 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
?: ?=(%born -.task)
Close dead connections on born.
2018-10-24 21:25:55 +03:00
:: close previously open connections
Boots with %light instead of %eyre. Stubs for system cofiguration events.
2018-09-28 21:24:41 +03:00
::
Close dead connections on born.
2018-10-24 21:25:55 +03:00
:: When we have a new unix process, every outstanding open connection is
:: dead. For every duct, send an implicit close connection.
::
=^ closed-connections=(list move) server-state.ax
=/ connections=(list [=^duct *])
~(tap by connections.server-state.ax)
::
=| closed-connections=(list move)
|-
?~ connections
[closed-connections server-state.ax]
::
=/ event-args
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
[[eny duct.i.connections now rof] server-state.ax]
Close dead connections on born.
2018-10-24 21:25:55 +03:00
=/ cancel-request cancel-request:(per-server-event event-args)
=^ moves server-state.ax cancel-request
::
$(closed-connections (weld moves closed-connections), connections t.connections)
updates %rver to save outgoing duct to unix
2019-04-10 00:03:21 +03:00
:: save duct for future %give to unix
::
=. outgoing-duct.server-state.ax duct
eyre: add cache
2023-03-25 07:18:25 +03:00
:: send all cache mappings to runtime
::
=/ cache-moves=(list move)
%+ turn ~(tap by cache.server-state.ax)
|= [url=@t cache-val=[aeon=@ud val=(unit cache-entry)]]
[duct %give %grow /cache/(scot %u aeon.cache-val)/(scot %t url)]
Close dead connections on born.
2018-10-24 21:25:55 +03:00
::
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
:_ http-server-gate
eyre: send valid auth tokens to the runtime Whenever a session gets created or removed, send the set of valid auth tokens to the runtime, so that it may use them in determining whether incoming requests are authenticated or not.
2022-08-24 01:34:08 +03:00
:* :: hand back default configuration for now
::
[duct %give %set-config http-config.server-state.ax]
:: provide a list of valid auth tokens
::
=< give-session-tokens
(per-server-event [eny duct now rof] server-state.ax)
Close dead connections on born.
2018-10-24 21:25:55 +03:00
::
eyre: add cache
2023-03-25 07:18:25 +03:00
(zing ~[closed-connections cache-moves])
Close dead connections on born.
2018-10-24 21:25:55 +03:00
==
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
::
?: ?=(%code-changed -.task)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
~> %slog.[0 leaf+"eyre: code-changed: throwing away local sessions"]
=* event-args [[eny duct now rof] server-state.ax]
:: find all the %ours sessions, we must close them
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
::
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
=/ siz=(list @uv)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
%+ murn ~(tap by sessions.auth.server-state.ax)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= [sid=@uv session]
?:(?=(%ours -.identity) (some sid) ~)
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
=| moves=(list (list move))
|- ^- [(list move) _http-server-gate]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
?~ siz
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
[(zing (flop moves)) http-server-gate]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
:: discard the session, clean up its channels
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=^ mov server-state.ax
(close-session:authentication:(per-server-event event-args) i.siz |)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
$(moves [mov moves], siz t.siz)
jael, eyre: Add a way to reset the web login code Jael now stores a `step` that is combined with the original salt to produce a new code. A `%step` card is used to increment that value, and effectively resetting the keys. Because the first `step` is zero, the first code is the same as before. Eyre was changed to be notified with `%code-changed` so it can forget old cookies, sessions and discard all the existing channels. A new generator was added |code, that does both querying and resetting the code |code :: shows current code, step and help |code %reset :: changes the code The old +code generator still works correctly.
2020-07-29 19:14:18 +03:00
::
eyre: add task for setting manual eauth base url
2023-05-22 22:08:11 +03:00
?: ?=(%eauth-host -.task)
=. user.endpoint.auth.server-state.ax host.task
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
=. time.endpoint.auth.server-state.ax now
eyre: add task for setting manual eauth base url
2023-05-22 22:08:11 +03:00
[~ http-server-gate]
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
:: all other commands operate on a per-server-event
Boots with %light instead of %eyre. Stubs for system cofiguration events.
2018-09-28 21:24:41 +03:00
::
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
=/ event-args [[eny duct now rof] server-state.ax]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
=/ server (per-server-event event-args)
Start filling out the request data structures.
2018-10-26 02:32:54 +03:00
::
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
?- -.task
:: %live: notifies us of the ports of our live http servers
Start filling out the request data structures.
2018-10-26 02:32:54 +03:00
::
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
%live
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
=. ports.server-state.ax +.task
eyre: add auto-https redirects if a cert is configured and a secure port is live it will set the redirect flag in http-config.state. When it gets a ++request it will return a 301 redirect to https://[host]/[path] if: 1. not already secure 2. redirect flag set 3. secure port live 4. is not requesting /.well-known/acme-challenge/... 5. the host is in domains.state It will not happen if forwarded-secured, localhost, local loopback, ip addresses or domains not in domains.state. in ++load it checks the secure port is live and a cert is set and enables it if so (for people who already use in-urbit letencrypt) %rule %cert tasks also toggle it (only turning it on if secure port live) %live tasks also toggle it (only turning it on if cert set) Have tested with a couple of ships and seems to work fine. This is useful in combination with pyry's auto arvo.network dns config system - can finally get rid of reverse proxies entirely.
2022-09-03 17:58:09 +03:00
:: enable http redirects if https port live and cert set
::
=. redirect.http-config.server-state.ax
&(?=(^ secure.task) ?=(^ secure.http-config.server-state.ax))
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[~ http-server-gate]
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
:: %rule: updates our http configuration
::
%rule
?- -.http-rule.task
:: %cert: install tls certificate
::
%cert
=* config http-config.server-state.ax
?: =(secure.config cert.http-rule.task)
[~ http-server-gate]
=. secure.config cert.http-rule.task
eyre: add auto-https redirects if a cert is configured and a secure port is live it will set the redirect flag in http-config.state. When it gets a ++request it will return a 301 redirect to https://[host]/[path] if: 1. not already secure 2. redirect flag set 3. secure port live 4. is not requesting /.well-known/acme-challenge/... 5. the host is in domains.state It will not happen if forwarded-secured, localhost, local loopback, ip addresses or domains not in domains.state. in ++load it checks the secure port is live and a cert is set and enables it if so (for people who already use in-urbit letencrypt) %rule %cert tasks also toggle it (only turning it on if secure port live) %live tasks also toggle it (only turning it on if cert set) Have tested with a couple of ships and seems to work fine. This is useful in combination with pyry's auto arvo.network dns config system - can finally get rid of reverse proxies entirely.
2022-09-03 17:58:09 +03:00
=. redirect.config
Update pkg/arvo/sys/vane/eyre.hoon Co-authored-by: fang <git@fang.io>
2022-09-29 03:32:32 +03:00
?& ?=(^ secure.ports.server-state.ax)
?=(^ cert.http-rule.task)
==
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
:_ http-server-gate
updates %rver to save outgoing duct to unix
2019-04-10 00:03:21 +03:00
=* out-duct outgoing-duct.server-state.ax
?~ out-duct ~
[out-duct %give %set-config config]~
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
:: %turf: add or remove domain name
::
%turf
=* domains domains.server-state.ax
various: move away from face/type syntax In favor of face=type.
2020-11-25 23:22:55 +03:00
=/ mod=(set turf)
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
?: ?=(%put action.http-rule.task)
(~(put in domains) turf.http-rule.task)
(~(del in domains) turf.http-rule.task)
?: =(domains mod)
[~ http-server-gate]
=. domains mod
:_ http-server-gate
=/ cmd
[%acme %poke `cage`[%acme-order !>(mod)]]
gall: implement local provenance
2023-05-22 16:12:09 +03:00
[duct %pass /acme/order %g %deal [our our /eyre] cmd]~
forward-ports http-config management to %rver
2019-03-21 08:28:32 +03:00
==
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
::
%plea
~| path.plea.task
?> ?=([%eauth %'0' ~] path.plea.task)
=+ plea=;;(eauth-plea payload.plea.task)
=^ moves server-state.ax
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
(on-plea:server:eauth:authentication:server ship.task plea)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[moves http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
::
eyre: fix tests
2019-11-14 06:38:13 +03:00
%request
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
=^ moves server-state.ax (request:server +.task)
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
adds rver side of localhost backdoor lens app stub
2019-04-30 23:38:40 +03:00
::
%request-local
=^ moves server-state.ax (request-local:server +.task)
[moves http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
::
%cancel-request
=^ moves server-state.ax cancel-request:server
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
::
%connect
=^ moves server-state.ax
%+ add-binding:server binding.task
[%app app.task]
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
::
%serve
=^ moves server-state.ax
%+ add-binding:server binding.task
[%gen generator.task]
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
Move the http client functionality to %http-client.
2019-02-09 00:16:42 +03:00
::
%disconnect
=. server-state.ax (remove-binding:server binding.task)
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[~ http-server-gate]
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
::
%approve-origin
=. cors-registry.server-state.ax
=, cors-registry.server-state.ax
:+ (~(del in requests) origin.task)
(~(put in approved) origin.task)
(~(del in rejected) origin.task)
[~ http-server-gate]
::
%reject-origin
=. cors-registry.server-state.ax
=, cors-registry.server-state.ax
:+ (~(del in requests) origin.task)
(~(del in approved) origin.task)
(~(put in rejected) origin.task)
[~ http-server-gate]
eyre %spew added to toggle verbosity
2023-02-08 23:20:07 +03:00
::
%spew
=. verb.server-state.ax veb.task
`http-server-gate
eyre: add cache
2023-03-25 07:18:25 +03:00
::
%set-response
=^ moves server-state.ax (set-response:server +.task)
[moves http-server-gate]
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
==
::
Send responses.
2018-09-24 21:48:19 +03:00
++ take
clay, eyre: add profiling hints
2021-03-28 10:47:37 +03:00
~/ %eyre-take
arvo: updates vane interface
2020-12-06 11:38:37 +03:00
|= [=wire =duct dud=(unit goof) =sign]
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
^- [(list move) _http-server-gate]
mall: convert lanaguage-server
2019-11-05 10:42:59 +03:00
=> %= .
sign
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?: ?=(%gall -.sign)
mall: convert lanaguage-server
2019-11-05 10:42:59 +03:00
?> ?=(%unto +<.sign)
sign
sign
==
Send responses.
2018-09-24 21:48:19 +03:00
:: :wire must at least contain two parts, the type and the build
::
First generator build ran.
2018-10-11 01:26:51 +03:00
?> ?=([@ *] wire)
Send responses.
2018-09-24 21:48:19 +03:00
::
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
|^ ^- [(list move) _http-server-gate]
Send responses.
2018-09-24 21:48:19 +03:00
::
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
?: ?=(%eauth i.wire)
eauth
?^ dud
~|(%eyre-take-dud (mean tang.u.dud))
eyre: make fang's requested style changes
2021-05-26 20:22:54 +03:00
?+ i.wire
~|([%bad-take-wire wire] !!)
Send responses.
2018-09-24 21:48:19 +03:00
::
eyre: make fang's requested style changes
2021-05-26 20:22:54 +03:00
%run-app-request run-app-request
%watch-response watch-response
%sessions sessions
%channel channel
%acme acme-ack
%conversion-cache `http-server-gate
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
==
Send responses.
2018-09-24 21:48:19 +03:00
::
Fix ~zod crash by fixing how %eyre handles app cancels. When we ask an app to run a %handle-http-cancel event, we don't actually care about the return value or even if it errors. The cancel event is purely informative. Likewise, because we cause cancels on restart of urbit, they cannot expose crashes to the system. Otherwise, an app with an open connection but a broken or non-existent cancel handler can prevent your ship from coming back up.
2019-07-26 00:12:44 +03:00
++ run-app-request
We now have an application path rendering
2018-10-03 21:36:45 +03:00
::
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%gall %unto *] sign)
A %coup failure from gall should return a 500 to the client.
2019-03-19 23:38:18 +03:00
::
::
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
?> ?=([%poke-ack *] p.sign)
eyre: cancel subscriptions more aggressively
2019-11-13 12:21:14 +03:00
?> ?=([@ *] t.wire)
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
?~ p.p.sign
:: received a positive acknowledgment: take no action
::
[~ http-server-gate]
:: we have an error; propagate it to the client
::
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
=/ event-args [[eny duct now rof] server-state.ax]
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
=/ handle-gall-error
handle-gall-error:(per-server-event event-args)
=^ moves server-state.ax
(handle-gall-error u.p.p.sign)
[moves http-server-gate]
::
++ watch-response
::
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
=/ event-args [[eny duct now rof] server-state.ax]
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
::
eyre: cancel subscriptions more aggressively
2019-11-13 12:21:14 +03:00
?> ?=([@ *] t.wire)
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?: ?=([%gall %unto %watch-ack *] sign)
A %coup failure from gall should return a 500 to the client.
2019-03-19 23:38:18 +03:00
?~ p.p.sign
:: received a positive acknowledgment: take no action
::
[~ http-server-gate]
:: we have an error; propagate it to the client
We now have an application path rendering
2018-10-03 21:36:45 +03:00
::
A %coup failure from gall should return a 500 to the client.
2019-03-19 23:38:18 +03:00
=/ handle-gall-error
handle-gall-error:(per-server-event event-args)
=^ moves server-state.ax (handle-gall-error u.p.p.sign)
[moves http-server-gate]
::
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?: ?=([%gall %unto %kick ~] sign)
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
=/ handle-response handle-response:(per-server-event event-args)
=^ moves server-state.ax
(handle-response %continue ~ &)
[moves http-server-gate]
Send responses.
2018-09-24 21:48:19 +03:00
::
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%gall %unto %fact *] sign)
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
=/ =mark p.cage.p.sign
=/ =vase q.cage.p.sign
?. ?= ?(%http-response-header %http-response-data %http-response-cancel)
mark
=/ handle-gall-error
handle-gall-error:(per-server-event event-args)
=^ moves server-state.ax
eyre: forego <atom> in favor of (scow %aura atom) Pretty-printing is expensive, yet we do it whenever we construct the cookie string, at least once (but usually twice) per authenticated request. Here we call out the the specific to-tape functions we need, instead of relying on the pretty-printer for converting... tapes to tapes, among other things. The primary gains come from the cookie-related instances, we update the others mostly for good style. For the "receive request and immediately send response" case, that is processed synchronously within eyre (ie, client sends channel ack), speeds thing up by roughly 55%.
2020-11-04 03:02:11 +03:00
(handle-gall-error leaf+"eyre bad mark {(trip mark)}" ~)
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
[moves http-server-gate]
::
=/ =http-event:http
?- mark
%http-response-header [%start !<(response-header:http vase) ~ |]
%http-response-data [%continue !<((unit octs) vase) |]
%http-response-cancel [%cancel ~]
==
Send responses.
2018-09-24 21:48:19 +03:00
=/ handle-response handle-response:(per-server-event event-args)
eyre: subscribe to apps for responses This removes the %http-response special case from gall. In its place, we implement a subscription regime with the following steps: - Agent sends %connect to Eyre - Eyre pokes agent with %handle-http-response, including unique eyre-id - Agent passes %start-watching to Eyre with eyre-id and unique app-id - Eyre subscribes to agent on /http-response/app-id - Agent produces a %http-response-header fact followed by 0 or more %http-response-data facts and possibly a %http-response-cancel fact - Agent produces a %kick to close the subscription, which Eyre interprets as completion of the message. This works when there is data. There is currently a bug where if the response has no data in total (as in the case of a naked 404), no response will be sent. This also includes lib/http-handler, which implements a convenient interface for agents that want to respond immediately with all the data. This lets them avoid carrying extra state to keep track of pending requests. This should really have access to your state and the ability to change it. Perhaps a more minimalist design would be better: just keep track of the requests, then hand it off to +on-watch when eyre is ready to receive responses. It's not clear how to pass in the request data in +on-watch.
2019-11-09 10:31:11 +03:00
=^ moves server-state.ax
(handle-response http-event)
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
Now with a test on the whole dummy-generator path.
2018-10-10 21:51:52 +03:00
::
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
++ channel
::
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
=/ event-args [[eny duct now rof] server-state.ax]
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
:: channel callback wires are triples.
::
?> ?=([@ @ @t *] wire)
::
?+ i.t.wire
~|([%bad-channel-wire wire] !!)
::
%timeout
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%behn %wake *] sign)
do nothing but print in %wake error case
2019-06-28 02:33:16 +03:00
?^ error.sign
[[duct %slip %d %flog %crud %wake u.error.sign]~ http-server-gate]
requested changes fixed
2023-02-16 18:02:34 +03:00
=* id i.t.t.wire
%- %+ trace:(per-server-event event-args) 1
|.("{(trip id)} cancelling channel due to timeout")
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
=^ moves server-state.ax
discard-channel traces fixed
2023-02-09 22:11:35 +03:00
(discard-channel:by-channel:(per-server-event event-args) id &)
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
eyre: add channel \n heartbeat every 20 seconds
2019-10-07 02:26:03 +03:00
::
%heartbeat
=/ on-channel-heartbeat
on-channel-heartbeat:by-channel:(per-server-event event-args)
=^ moves server-state.ax
(on-channel-heartbeat i.t.t.wire)
[moves http-server-gate]
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
::
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
?(%poke %subscription)
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%gall %unto *] sign)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
~| eyre-sub=wire
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
?> ?=([@ @ @t @ *] wire)
gall: allow apps to run from any desk Start with |start %desk %app-name Everywhere in the kernel that we deal with marks, we infer the app it's connected to and use the marks from that desk. Also some light renaming in gall, especially path->wire and current-agent->yoke. Subsequent tasks: - Dojo needs a syntax to run generators and threads from other desks - The home desk should be split into at least a minimal base desk and big "userspace" desk. Dill's initialization logic should be updated to handle - |show-package, |install, and |uninstall should to be written - Clay should have smarter handling of system versions instead of just ignoring what's on each desk. It's not clear that this will work correctly when sys updates right now.
2021-06-19 05:13:55 +03:00
?< ?=(%raw-fact -.p.sign)
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
=* channel-id i.t.t.wire
=* request-id i.t.t.t.wire
=* extra-wire t.t.t.t.wire
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
=/ on-gall-response
on-gall-response:by-channel:(per-server-event event-args)
Timer demo works again, but now based on subscriptions. - Resubscribes because Gall currently breaks connections after 20 messages on a subscription. - Fixes cleanup of connections, so we don't constantly leak closed connections into set of open connections, leading to spam cleanup on restart of your urbit.
2019-01-11 03:35:09 +03:00
:: ~& [%gall-response sign]
First transimsission of text/event-stream from Eyre.
2018-11-21 04:06:04 +03:00
=^ moves server-state.ax
eyre: send %leave on %fact/ack for deleted channel Ordinarily, eyre cleans up the relevant gall subscriptions whenever a channel disappears. In yet unresolved erroneous behavior though, it may leave a gall subscription open, despite wiping the channel from state. Attempting to pass the response onto the deleted channel anyway results in an %eyre-no-channel error later in the event. The volume of these errors can degrade the user experience, as per #3196. To resolve the annoyance (but not the underlying issue) we detect the "subscription has no channel" case, and issue a %leave. Doing so requires additional information in the wire, so we add that in, refactoring the relevant wire building along the way. Note that due to the wire requirements, this cannot resolve existing cases. For that, we depend on bc929ba6d.
2020-08-27 14:47:18 +03:00
%- on-gall-response
[channel-id (slav %ud request-id) extra-wire p.sign]
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
[moves http-server-gate]
Receive callback timers from behn which cancel open subscriptions.
2018-11-20 01:59:58 +03:00
==
updates %rver to handle %gall's ack after poking :acme
2019-04-08 23:17:19 +03:00
::
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
++ sessions
::
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%behn %wake *] sign)
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
::
?^ error.sign
[[duct %slip %d %flog %crud %wake u.error.sign]~ http-server-gate]
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
::NOTE we are not concerned with expiring channels that are still in
:: use. we require acks for messages, which bump their session's
:: timer. channels have their own expiry timer, too.
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
:: remove cookies that have expired
::
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=* sessions sessions.auth.server-state.ax
=. sessions.auth.server-state.ax
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
%- ~(gas by *(map @uv session))
eyre, zuse: expire channels with their sessions Associates channels with the authentication sessions that opened them, and deletes the channel when its associated session expires. Also updates the debug dashboard to display channel counts per session.
2020-06-04 23:06:13 +03:00
%+ skip ~(tap in sessions)
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
|= [cookie=@uv session]
eyre, zuse: expire channels with their sessions Associates channels with the authentication sessions that opened them, and deletes the channel when its associated session expires. Also updates the debug dashboard to display channel counts per session.
2020-06-04 23:06:13 +03:00
(lth expiry-time now)
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
:: if there's any cookies left, set a timer for the next expected expiry
::
^- [(list move) _http-server-gate]
:_ http-server-gate
eyre: send valid auth tokens to the runtime Whenever a session gets created or removed, send the set of valid auth tokens to the runtime, so that it may use them in determining whether incoming requests are authenticated or not.
2022-08-24 01:34:08 +03:00
:- =< give-session-tokens
(per-server-event [eny duct now rof] server-state.ax)
eyre: clear expired sessions/cookies from state Instead of setting a timer for every session, we set a single expiry timer when the first session is created. On the subsequent wake event, we clear all cookies that have expired at that time, then set a timer for when the next session expires. This approach gives us flexibility wrt sessions going forward, allowing extending or early deleting of sessions without having to care about the related timers. Note that in +load, we clear all existing sessions. We would start the expiry timer flow there, but can't. Forcing the user to login again post-ota once isn't the end of the world.
2020-05-29 16:28:13 +03:00
?: =(~ sessions) ~
=; next-expiry=@da
[duct %pass /sessions/expire %b %wait next-expiry]~
%+ roll ~(tap by sessions)
|= [[@uv session] next=@da]
?: =(*@da next) expiry-time
(min next expiry-time)
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
++ eauth
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
=* auth auth.server-state.ax
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=* args [[eny duct now rof] server-state.ax]
^- [(list move) _http-server-gate]
~| [wire +<.sign]
?+ t.wire !!
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
[%plea @ ~]
=/ =ship (slav %p i.t.t.wire)
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
::
?: |(?=(^ dud) ?=([%ames %lost *] sign))
eyre: up priority on unexpected eauth traces These are more "warning" or "error" as opposed to informational like all the other ones at level 2.
2023-05-23 23:39:48 +03:00
%- %+ trace:(per-server-event args) 0
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
?~ dud |.("eauth: lost boon from {(scow %p ship)}")
|.("eauth: crashed on %{(trip +<.sign)} from {(scow %p ship)}")
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
::NOTE when failing on pending attempts, we just wait for the timer
:: to clean up. when failing on live sessions, well, we should
:: just be careful not to crash when receiving %shut boons.
:: (we do not want to have the nonce in the wire, so this is the
:: best handling we can do. the alternative is tracking)
[~ http-server-gate]
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
::
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
?: ?=([%ames %done *] sign)
eyre: keep queue for outgoing pleas Keeping a queue of nonces to match the outgoing %pleas we send lets us recover the nonce for the %done we receive in response. This is important in the nack case, where we may want to eagerly serve the HTTP client an error page response, instead of waiting for the timeout timer to fire.
2023-06-27 23:58:22 +03:00
=^ moz server-state.ax
%. [ship ?=(~ error.sign)]
on-done:client:eauth:authentication:(per-server-event args)
[moz http-server-gate]
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
::
?> ?=([%ames %boon *] sign)
=/ boon ;;(eauth-boon payload.sign)
=^ moz server-state.ax
%. [ship boon]
on-boon:client:eauth:authentication:(per-server-event args)
[moz http-server-gate]
::
[%keen @ @ ~]
=/ client=@p (slav %p i.t.t.wire)
=/ nonce=@uv (slav %uv i.t.t.t.wire)
::
?^ dud
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=^ moz server-state.ax
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
%. [client nonce]
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
on-fail:server:eauth:authentication:(per-server-event args)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[moz http-server-gate]
eyre: handle %lost and goof error cases correctly We weren't handling these at all. Now we make them enter the same codepath that %done nacks go into: deleting the attempt and maybe telling the user if we can. Note that Eyre will not receive %lost for %boons it crashes on until
2023-05-23 23:29:08 +03:00
::
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?> ?=([%ames %tune *] sign)
?> =(client ship.sign)
=/ url=(unit @t)
?~ roar.sign ~
?~ q.dat.u.roar.sign ~
;;((unit @t) q.u.q.dat.u.roar.sign)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
=^ moz server-state.ax
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
?~ url
%. [client nonce]
on-fail:server:eauth:authentication:(per-server-event args)
%. [client nonce u.url]
on-tune:server:eauth:authentication:(per-server-event args)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[moz http-server-gate]
::
[%expire %visiting @ @ ~]
?> ?=([%behn %wake *] sign)
=/ server=@p (slav %p i.t.t.t.wire)
=/ nonce=@uv (slav %uv i.t.t.t.t.wire)
eyre: move incoming eauth expiry logic into +eauth +expiry:client:eauth, to be precise. This is a slightly cleaner factoring.
2023-05-23 23:37:05 +03:00
=^ moz server-state.ax
%. [server nonce]
expire:client:eauth:authentication:(per-server-event args)
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[~ http-server-gate]
::
[%expire %visitors @ ~]
=/ nonce=@uv (slav %uv i.t.t.t.wire)
=^ moz server-state.ax
(expire:server:eauth:authentication:(per-server-event args) nonce)
[moz http-server-gate]
==
::
updates %rver to handle %gall's ack after poking :acme
2019-04-08 23:17:19 +03:00
++ acme-ack
arvo: full vane names in $sign
2020-12-08 03:22:26 +03:00
?> ?=([%gall %unto *] sign)
updates %rver to handle %gall's ack after poking :acme
2019-04-08 23:17:19 +03:00
::
mall: convert lanaguage-server
2019-11-05 10:42:59 +03:00
?> ?=([%poke-ack *] p.sign)
updates %rver to handle %gall's ack after poking :acme
2019-04-08 23:17:19 +03:00
?~ p.p.sign
:: received a positive acknowledgment: take no action
::
[~ http-server-gate]
:: received a negative acknowledgment: XX do something
::
[((slog u.p.p.sign) ~) http-server-gate]
Send responses.
2018-09-24 21:48:19 +03:00
--
::
Initial split of %light into %http-server and %http-client
2019-02-09 02:03:46 +03:00
++ http-server-gate ..$
Boots with %light instead of %eyre. Stubs for system cofiguration events.
2018-09-28 21:24:41 +03:00
:: +load: migrate old state to new state (called on vane reload)
::
++ load
+load properly migrates state
2023-02-08 23:10:16 +03:00
=> |%
+$ axle-any
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
$% [date=%~2020.10.18 server-state=server-state-0]
[date=%~2022.7.26 server-state=server-state-0]
[date=%~2023.2.17 server-state=server-state-1]
[date=%~2023.3.16 server-state=server-state-2]
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
[date=%~2023.4.11 server-state-3]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
[date=%~2023.5.15 server-state]
+load properly migrates state
2023-02-08 23:10:16 +03:00
==
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
::
+load properly migrates state
2023-02-08 23:10:16 +03:00
+$ server-state-0
$: bindings=(list [=binding =duct =action])
=cors-registry
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
connections=(map duct outstanding-connection-3)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth=authentication-state-3
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
channel-state=channel-state-2
+load properly migrates state
2023-02-08 23:10:16 +03:00
domains=(set turf)
=http-config
ports=[insecure=@ud secure=(unit @ud)]
outgoing-duct=duct
==
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
::
eyre: add cache
2023-03-25 07:18:25 +03:00
+$ server-state-1
$: bindings=(list [=binding =duct =action])
=cors-registry
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
connections=(map duct outstanding-connection-3)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth=authentication-state-3
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
channel-state=channel-state-2
domains=(set turf)
=http-config
ports=[insecure=@ud secure=(unit @ud)]
outgoing-duct=duct
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
verb=@ :: <- new
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
==
::
+$ server-state-2
$: bindings=(list [=binding =duct =action])
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
cache=(map url=@t [aeon=@ud val=(unit cache-entry)]) :: <- new
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
=cors-registry
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
connections=(map duct outstanding-connection-3)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth=authentication-state-3
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
channel-state=channel-state-2
eyre: add cache
2023-03-25 07:18:25 +03:00
domains=(set turf)
=http-config
ports=[insecure=@ud secure=(unit @ud)]
outgoing-duct=duct
verb=@
==
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
+$ channel-state-2
$: session=(map @t channel-2)
duct-to-key=(map duct @t)
==
+$ channel-2
$: state=(each timer duct)
next-id=@ud
last-ack=@da
eyre: combine unreleased loads for ~2023.4.19 and ~2023.4.11
2023-04-24 18:54:22 +03:00
events=(qeu [id=@ud request-id=@ud channel-event=channel-event-2])
Merge branch 'next/kelvin/413' into x/json-bgon
2023-04-11 22:54:43 +03:00
unacked=(map @ud @ud)
subscriptions=(map @ud [ship=@p app=term =path duc=duct])
heartbeat=(unit timer)
==
eyre: combine unreleased loads for ~2023.4.19 and ~2023.4.11
2023-04-24 18:54:22 +03:00
+$ channel-event-2
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
$% $>(%poke-ack sign:agent:gall)
$>(%watch-ack sign:agent:gall)
$>(%kick sign:agent:gall)
[%fact =mark =noun]
==
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
+$ server-state-3
$: bindings=(list [=binding =duct =action])
cache=(map url=@t [aeon=@ud val=(unit cache-entry)])
=cors-registry
connections=(map duct outstanding-connection-3)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth=authentication-state-3
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
channel-state=channel-state-3
domains=(set turf)
=http-config
ports=[insecure=@ud secure=(unit @ud)]
outgoing-duct=duct
verb=@
==
+$ outstanding-connection-3
$: =action
=inbound-request
response-header=(unit response-header:http)
bytes-sent=@ud
==
+$ authentication-state-3 sessions=(map @uv session-3)
+$ session-3
$: expiry-time=@da
channels=(set @t)
==
+$ channel-state-3
$: session=(map @t channel-3)
duct-to-key=(map duct @t)
==
+$ channel-3
$: mode=?(%json %jam)
state=(each timer duct)
next-id=@ud
last-ack=@da
events=(qeu [id=@ud request-id=@ud =channel-event])
unacked=(map @ud @ud)
subscriptions=(map @ud [ship=@p app=term =path duc=duct])
heartbeat=(unit timer)
==
+load properly migrates state
2023-02-08 23:10:16 +03:00
--
|= old=axle-any
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
^+ http-server-gate
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
?- -.old
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
::
:: adds /~/name
::
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
%~2020.10.18
eyre: refactor +load to be prettier
2022-08-11 19:32:49 +03:00
%= $
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
date.old %~2022.7.26
::
bindings.server-state.old
%+ insert-binding
[[~ /~/name] outgoing-duct.server-state.old [%name ~]]
bindings.server-state.old
==
::
:: enables https redirects if certificate configured
:: inits .verb
eyre: add /~/name endpoint
2022-08-01 01:50:36 +03:00
::
%~2022.7.26
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
=. redirect.http-config.server-state.old
?& ?=(^ secure.ports.server-state.old)
?=(^ secure.http-config.server-state.old)
==
$(old [%~2023.2.17 server-state.old(|8 [|8 verb=0]:server-state.old)])
::
:: inits .cache
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
::
+load fixed
2023-02-17 19:15:27 +03:00
%~2023.2.17
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
$(old [%~2023.3.16 [bindings ~ +]:server-state.old])
::
eyre: combine unreleased loads for ~2023.4.19 and ~2023.4.11
2023-04-24 18:54:22 +03:00
:: inits channel mode and desks in unacked events
eyre: add support for noun-based channels Adds a "mode" to channels, which can be set to either %json (current behavior) or %jam. For %jam channels, aside from the SSE framing, all communication happens through @uw-encoded jammed nouns. This applies to both outgoing channel events, as well as incoming channel requests. We choose @uw-style encoding because raw bytestreams are fragile and cannot work inside the SSE stream context. Currently, a separate endpoint (/~/channel-jam/etc) is used to indicate %jam as the desired mode for a channel. We will probably want to make this a bit cleaner, not least because it's not currently implemented as a formal standalone endpoint, but also to give it stronger aesthetic equivalence with the existing channel endpoint. Putting the mode in the file extension is a tempting option here, but semantically not quite right. Connecting to the same channel across multiple modes is currently supported, but it's untested, and unclear whether this is desirable or not.
2022-07-04 18:05:13 +03:00
::
eyre: add cache
2023-03-25 07:18:25 +03:00
%~2023.3.16
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
::
:: Prior to this desks were not part of events.channel.
:: When serializing we used to rely on the desk stored in
:: subscriptions.channel, but this state is deleted when we clog.
:: This migration adds the desk to events.channel, but we can not
:: scry in +load to populate the desks in the old events,
:: so we just kick all subscriptions on all channels.
eyre: combine unreleased loads for ~2023.4.19 and ~2023.4.11
2023-04-24 18:54:22 +03:00
%= $
date.old %~2023.4.11
::
server-state.old
%= server-state.old
session.channel-state
%- ~(run by session.channel-state.server-state.old)
|= c=channel-2
=; new-events
:- %json
c(events new-events, unacked ~, subscriptions ~)
=| events=(qeu [id=@ud request-id=@ud =channel-event])
=/ l ~(tap in ~(key by subscriptions.c))
|-
?~ l events
%= $
l t.l
next-id.c +(next-id.c)
events (~(put to events) [next-id.c i.l %kick ~])
==
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
==
==
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
:: guarantees & stores a session for each request, and a @p identity for
:: each session and channel
lull, eyre: actually send events on clogged channel reconnect
2023-04-20 16:18:52 +03:00
::
eyre: combine unreleased loads for ~2023.4.19 and ~2023.4.11
2023-04-24 18:54:22 +03:00
%~2023.4.11
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%= $
eyre: collapse recent state update logic The guest identities (#6561) and EAuth (#6598) features will both be released as part of Zuse 412K, so their +load logic can be collapsed into a single step.
2023-06-28 00:06:32 +03:00
date.old %~2023.5.15
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
::
connections.old
%- ~(run by connections.old)
|= outstanding-connection-3
^- outstanding-connection
[action inbound-request [*@uv [%ours ~]] response-header bytes-sent]
::
eyre: collapse recent state update logic The guest identities (#6561) and EAuth (#6598) features will both be released as part of Zuse 412K, so their +load logic can be collapsed into a single step.
2023-06-28 00:06:32 +03:00
auth.old
:_ [~ ~ [~ ~ now]]
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
%- ~(run by sessions.auth.old)
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
|= s=session-3
^- session
[[%ours ~] s]
::
session.channel-state.old
%- ~(run by session.channel-state.old)
|= c=channel-3
^- channel
[-.c [%ours ~] +.c]
eyre: update %name, add %host endpoint %name now returns the identity of the session associated with the request. %host will always return the @p of the ship *handling* the request. The latter becomes especially important for guest sessions, who can only interact with agents on the local ship, but will still need to specify who that ship is.
2023-05-06 00:38:40 +03:00
::
bindings.old
eyre: collapse recent state update logic The guest identities (#6561) and EAuth (#6598) features will both be released as part of Zuse 412K, so their +load logic can be collapsed into a single step.
2023-06-28 00:06:32 +03:00
%+ insert-binding [[~ /~/host] outgoing-duct.old [%host ~]]
%+ insert-binding [[~ /~/eauth] outgoing-duct.old [%eauth ~]]
eyre: eauth, cross-ship authentication aka "mirage" aka "eyre oauth" With Eyre now supporting both local identity authentication, and fake guest identities, the logical next step is to support authentication with real non-local identities. Here, we implement that, building on top of the groundwork laid by #6561. The primary change is adding a %real case to Eyre's $identity type, and implementing an http<->ames<->ames handshaking protocol into Eyre for negotiating approval of login attempts made by unauthenticated HTTP clients. The authentication flow, where a "visitor" logs into a "~host" as their own "~client" identity can be described in brief as follows: 1) Visitor makes an HTTP request saying they are ~client. 2) ~host tells ~client, over Ames, about its own public-facing hostname. 3) ~client responds with its own public-facing hostname. 4) ~host forwards the visitor to ~client's eauth page. 5) Visitor, there already logged in as ~client, approves the login attempt. 6) ~client shares a secret with ~host over Ames, and forwards the visitor to ~host's eauth page, including the secret in the request. 7) ~host sees that the secrets received over Ames and HTTP match, and gives the visitor a new session token, identifying them as ~client. The negotiating of hostnames/URLs via Ames is crucial to keeping this handshake sequence secure. Discovering a ship's public-facing hostname happens when successful local logins are made by reading out the Host header from the request. Users may hard-code a value to override this. Each eauth login attempt comes with a unique nonce. Both the host and client track the lifetime of these. The corresponding Ames flow (which goes from ~host -> ~client) is corked when the login attempt gets aborted, or its associated session expires. The logout functionality has been updated to let clients ask to be logged out of sessions on other ships.
2023-05-18 22:40:58 +03:00
bindings.old
==
::
%~2023.5.15
eyre: further refactor +load logic Co-authored by: joemfb <joemfb@gmail.com>
2023-04-12 19:53:00 +03:00
http-server-gate(ax old)
+load properly migrates state
2023-02-08 23:10:16 +03:00
==
Boots with %light instead of %eyre. Stubs for system cofiguration events.
2018-09-28 21:24:41 +03:00
:: +stay: produce current state
::
++ stay `axle`ax
:: +scry: request a path in the urbit namespace
::
++ scry
clay, eyre: add profiling hints
2021-03-28 10:47:37 +03:00
~/ %eyre-scry
arvo: reform of the scry reform
2020-12-08 00:52:12 +03:00
^- roon
gall: implement local provenance
2023-05-22 16:12:09 +03:00
|= [lyc=gang pov=path car=term bem=beam]
forward-ports /=host= scry to %rver
2019-03-21 09:01:38 +03:00
^- (unit (unit cage))
arvo: reform of the scry reform
2020-12-08 00:52:12 +03:00
=* ren car
arvo: scry reform
2020-11-24 00:06:50 +03:00
=* why=shop &/p.bem
=* syd q.bem
=/ lot=coin $/r.bem
=* tyl s.bem
::
forward-ports /=host= scry to %rver
2019-03-21 09:01:38 +03:00
?. ?=(%& -.why)
~
=* who p.why
arvo: restructures |mass, switches to %x //whey
2023-04-24 23:01:00 +03:00
::
forward-ports /=host= scry to %rver
2019-03-21 09:01:38 +03:00
?. ?=(%$ -.lot)
[~ ~]
?. =(our who)
?. =([%da now] p.lot)
[~ ~]
~& [%r %scry-foreign-host who]
~
arvo: restructures |mass, switches to %x //whey
2023-04-24 23:01:00 +03:00
?: &(?=(%x ren) ?=(%$ syd))
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
=, server-state.ax
?+ tyl [~ ~]
arvo: restructures |mass, switches to %x //whey
2023-04-24 23:01:00 +03:00
[%$ %whey ~] =- ``mass+!>(`(list mass)`-)
:~ bindings+&+bindings.server-state.ax
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
auth+&+auth.server-state.ax
arvo: restructures |mass, switches to %x //whey
2023-04-24 23:01:00 +03:00
connections+&+connections.server-state.ax
channels+&+channel-state.server-state.ax
axle+&+ax
==
::
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
[%cors ~] ``noun+!>(cors-registry)
[%cors %requests ~] ``noun+!>(requests.cors-registry)
[%cors %approved ~] ``noun+!>(approved.cors-registry)
[%cors %rejected ~] ``noun+!>(rejected.cors-registry)
::
[%cors ?(%approved %rejected) @ ~]
=* kind i.t.tyl
=* orig i.t.t.tyl
?~ origin=(slaw %t orig) [~ ~]
?- kind
%approved ``noun+!>((~(has in approved.cors-registry) u.origin))
%rejected ``noun+!>((~(has in rejected.cors-registry) u.origin))
==
eyre: rework eauth to be client-initiated Instead of doing formal network traffic on the host-side whenever a login attempt gets initiated, we now do it no earlier than when we're on the client-side. This has the important property that network traffic can only be initiated by authenticated HTTP requests. The previous implementation, where hosts sent pleas when an unauthenticated HTTP client said then wanted to log in, was vulnerable to abuse. So now, formally, the eauth flow starts at the client's confirmation screen. There is an optional step preceding this, where an attempt is started on the host (and data is still stored for this), but to get the redirect target, the host uses remote scry to get the eauth URL out of the client ship. Hosts now also give attempt-specific return URLs, useful in case they are accessible (or even serving different content) from different hostnames.
2023-06-09 16:46:04 +03:00
::
[%eauth %url ~]
=* endpoint endpoint.auth.server-state.ax
?. ?=(%da -.p.lot) [~ ~]
:: we cannot answer for something prior to the last set time,
:: or something beyond the present moment.
::
?: ?| (lth q.p.lot time.endpoint)
(gth q.p.lot now)
==
~
:^ ~ ~ %noun
!> ^- (unit @t)
=< eauth-url:eauth:authentication
(per-server-event [eny *duct now rof] server-state.ax)
eyre: add authentication checker scry endpoint Lets you check whether a specific Cookie header value string constitutes an authenticated request. /ex/=//=/authenticated/cookie/(scot %t 'cookie-string') Intended for use in the runtime, for example with #3557.
2020-10-01 20:55:16 +03:00
::
[%authenticated %cookie @ ~]
?~ cookies=(slaw %t i.t.t.tyl) [~ ~]
:^ ~ ~ %noun
!> ^- ?
eyre: guest ids for unauthenticated requests aka "the open eyre" aka "universal basic identity" Urbit already supports presence on the clearnet, but fails to expose any of its interactive affordances to unauthenticated users. Here, we improve this situation by granting "guest identity" @ps to every unauthenticated HTTP request, and extending the channels functionality to them. Sessions no longer represent only the local identity. Instead, each session has either the local identity, or a fake guest identity associated with it. Every request that does not provide a session key/cookie gets assigned a fresh one with a guest identity on the spot. As a result, every single request has an identity associated with it. The identity of a request gets propagated into userspace, if the request ends up there. For normal HTTP requests, this means the src.bowl gets set to that identity for both the watch and poke of the request. For backwards compatibility, the authenticated flag on the request noun gets set at normal: only true if the request came from the local identity. For channel requests, this means the src.bowl gets set to that identity for any pokes and watches it sends, and it can only send those to agents running on the local ship. The scry endpoint remains unchanged in its behavior: only available to the local identity. Notable implementation detail changes in this diff include: - Factored all gall interactions out into +deal-as. - Sessions no longer represent exclusively the local identity. This matters a lot to +give-session-tokens, %code-changed, and logout handling. - Session management got factored out into explicit +start-session and +close-session arms.
2023-05-05 22:59:17 +03:00
%- =< request-is-authenticated:authentication
arvo: completes scry reform
2020-12-06 13:55:19 +03:00
(per-server-event [eny *duct now rof] server-state.ax)
eyre: add authentication checker scry endpoint Lets you check whether a specific Cookie header value string constitutes an authenticated request. /ex/=//=/authenticated/cookie/(scot %t 'cookie-string') Intended for use in the runtime, for example with #3557.
2020-10-01 20:55:16 +03:00
%*(. *request:http header-list ['cookie' u.cookies]~)
eyre: add cache
2023-03-25 07:18:25 +03:00
::
[%cache @ @ ~]
?~ aeon=(slaw %ud i.t.tyl) [~ ~]
?~ url=(slaw %t i.t.t.tyl) [~ ~]
?~ entry=(~(get by cache) u.url) [~ ~]
?. =(u.aeon aeon.u.entry) [~ ~]
?~ val=val.u.entry [~ ~]
``noun+!>(u.val)
eyre: minimal CORS support Adds a cors-registry to Eyre's state that tracks allowed and rejected origins for the purposes of CORS request handling. For preflight requests, generates a response in-line. For simple requests, adds CORS headers onto whatever response is given. See also: https://groups.google.com/a/urbit.org/g/dev/c/bb82dwEJGzM/m/q2JjNSx5BwAJ
2020-09-30 16:07:27 +03:00
==
?. ?=(%$ ren)
[~ ~]
eyre, zuse: add scry interfaces for eyre state Scries for getting out open connections, cookie sessions, and existing channels. Moves the involved types from eyre into zuse.
2020-05-23 00:55:17 +03:00
?+ syd [~ ~]
lull, eyre: remove scry adapters for /~/name endpoint
2023-03-03 02:00:27 +03:00
%bindings ``noun+!>(bindings.server-state.ax)
%connections ``noun+!>(connections.server-state.ax)
eyre: rename authentication-state to auth Only in the $server-state type, the lull typename remains unchanged (for now). "authentication-state" is just such a mouthful!
2023-05-19 12:31:01 +03:00
%authentication-state ``noun+!>(auth.server-state.ax)
eyre, zuse: add scry interfaces for eyre state Scries for getting out open connections, cookie sessions, and existing channels. Moves the involved types from eyre into zuse.
2020-05-23 00:55:17 +03:00
%channel-state ``noun+!>(channel-state.server-state.ax)
forward-ports /=host= scry to %rver
2019-03-21 09:01:38 +03:00
::
eyre, zuse: add scry interfaces for eyre state Scries for getting out open connections, cookie sessions, and existing channels. Moves the involved types from eyre into zuse.
2020-05-23 00:55:17 +03:00
%host
%- (lift (lift |=(a=hart:eyre [%hart !>(a)])))
^- (unit (unit hart:eyre))
=. p.lot ?.(=([%da now] p.lot) p.lot [%tas %real])
?+ p.lot
[~ ~]
::
[%tas %fake]
``[& [~ 8.443] %& /localhost]
::
[%tas %real]
=* domains domains.server-state.ax
=* ports ports.server-state.ax
=/ =host:eyre [%& ?^(domains n.domains /localhost)]
=/ port=(unit @ud)
eyre: fix %host scry so it still says secure if localhost
2022-12-01 04:17:23 +03:00
?. ?=(^ secure.ports)
eyre, zuse: add scry interfaces for eyre state Scries for getting out open connections, cookie sessions, and existing channels. Moves the involved types from eyre into zuse.
2020-05-23 00:55:17 +03:00
?:(=(80 insecure.ports) ~ `insecure.ports)
?:(=(443 u.secure.ports) ~ secure.ports)
eyre: provide proper secure flag in %host scry
2023-01-27 16:16:45 +03:00
``[?=(^ secure.ports) port host]
eyre, zuse: add scry interfaces for eyre state Scries for getting out open connections, cookie sessions, and existing channels. Moves the involved types from eyre into zuse.
2020-05-23 00:55:17 +03:00
==
forward-ports /=host= scry to %rver
2019-03-21 09:01:38 +03:00
==
Data types, basic tests, and a router.
2018-09-20 02:29:36 +03:00
--
Reference in New Issue Copy Permalink