auth in fastn

[amitu]

We rely on external group definitions

providers let us define group

-- fastn.user-group: <name-of-group>
<privider-specific-key>: <that-key's parameter>

-- fastn.package: community/github
auth: true

-- fastn.auth-stuff:
profile-info-provided: id, name, email

-- fastn.auth-key: github-username

This group contains people who have this exact github username.


-- fastn.auth-key: has-sponsored-github-user

Anyone who has sponsored this user on Github belongs to this group.

Auth Dependency Communication

• Generic: via groups

• Generic profile:

Every auth provider has to provide community/auth

-- fastn.package: community/auth
system: true

-- import: community/auth

-- optional string: $auth.get-id() 

-- import: fastn
-- fastn.package: amitu.com

-- fastn.dependency: community/auth
via: amitu.com/github

-- fastn.auth: community/github
mount-point: /github/
config: amitu.com/github-config

[amitu]

In Rithik's slides case:

-- import: fastn
-- fastn.package: slides.fifthtry.com

- fastn.dependency: fastn-community.github.io/design-system
auto-import: ds
- fastn.dependency: fastn-community.github.io/postgresql-db
auto-import: db
- fastn.dependency: fastn-community.github.io/auth
auto-import: auth

-- fastn.auth: fastn-community.github.io/github
mount-point: /github/
config: slides.fifthtry.com/github-config ;; client id, secret, redirect url etc
postgresql-db: slides.fifthtry.com/db

get-auth-list(): auth.auth list

-- record auth:
string provider: 
string id:
optional string name:
optional string email:

[amitu]

Multi Auth

-- import: fastn
-- fastn.package: slides.fifthtry.com

- fastn.dependency: fastn-community.github.io/design-system
auto-import: ds
- fastn.dependency: fastn-community.github.io/postgresql-db
auto-import: db
- fastn.dependency: fastn-community.github.io/multi-auth
auto-import: auth
via: slides.fifthtry.com/multi-auth

-- fastn.auth: fastn-community.github.io/github
mount-point: /github/
config: slides.fifthtry.com/github-config ;; client id, secret, redirect url etc
postgresql-db: slides.fifthtry.com/db

-- fastn.auth: fastn-community.github.io/google
mount-point: /google/
config: slides.fifthtry.com/google-config ;; client id, secret, redirect url etc
postgresql-db: slides.fifthtry.com/db

multi-auth.ftd

-- import: fastn-community.github.io/multi-auth
exposing: *

-- provider list providers:
-- provider: github
import-path: /github/
-- provider: google
import: path: /google/
-- end: providers

[siddhantk232]

Expanding on this: github.com/orgs/fastn-stack/discussions/1484#discussioncomment-7550579 and some questions:

fastn-community.github.io/auth's FASTN.ftd file:

-- import: fastn

-- fastn.package: fastn-community.github.io/auth
system: fastn-community.github.io/auth/config

fastn-comunnity.github.io/auth/config.ftd file:

-- import: fastn-community.github.io/auth

-- optional string user_id: id coming from auth system package

slides.fifthtry.com's FASTN.ftd

-- import: fastn

-- fastn.package: slides.fifthtry.com

-- fastn.dependency: fastn-community.github.io/auth
auto-import: auth

-- fastn.auth: fastn-community.github.io/github
mount-point: /github/
config: slides.fifthtry.com/github-config ;; client id, secret, redirect url etc

• The reason we say auto-import: auth above so that any module in slides.fifthtry.com can use things specified in the system package fastn-community.github.io/auth (auth.user_id in this case).
• fastn.auth is similar to fastn.app so mount-point: works exactly as described here.
• We are able to provide config to this github auth package.

Questions

• Any module inside slides.fifthtry.com can use auth which will actually use fastn-community.github.io/github? Example:

;; index.ftd file of slides.fifthtry.com

-- ftd.text: $auth.user_id ;; auth auto imported in FASTN.ftd

• If the answer to above is yes. Shouldn't the FASTN.ftd of slides.fifthtry.com be something like shown below?

-- import: fastn

-- fastn.package: slides.fifthtry.com

-- fastn.dependency: fastn-community.github.io/auth
provides-via: fastn-community.github.io/github
auto-import: auth

-- fastn.app: fastn-community.github.io/github
mount-point: /github/
config: slides.fifthtry.com/github-config ;; client id, secret, redirect url etc

• github is an app (registers /login and /callback urls). But, github auth package also implements fastn-community.github.io/auth so this package can be used like this as well.
• This clearly indicates that call to auth.user_id will be handled by the implementation of user_id of fastn-community.github.io/github
• The point I'm trying to make here is that the indirection that auth.user_id is github.user_id in your example is not clear to me. How id fastn-community.github.io/github is providing impl for fastn-community.github.io/auth here?
• I would love a possible definition of fastn-community.github.io/github's FASTN.ftd and fastn-community.github.io/auth's FASTN.ftd from you (@amitu).

[amitu]

In the second code snippet:

-- import: fastn-community.github.io/auth

-- optional string user_id: id coming from auth system package

The import statement is not needed.

Also if you are defining a default value, maybe user_id should not be defined as optional.

Also auth.user-id() is meant to be a function, not a variable. Technically we can try to make variable also work, we have special variables, that when accessed invoke Rust code, and can put logic there, but there is no mechanism to define such special variables without wasm support.

[amitu]

This snippet:

-- import: fastn

-- fastn.package: slides.fifthtry.com

-- fastn.dependency: fastn-community.github.io/auth
auto-import: auth

-- fastn.auth: fastn-community.github.io/github
mount-point: /github/
config: slides.fifthtry.com/github-config ;; client id, secret, redirect url etc

This is wrong,

-- import: fastn
-- fastn.package: amitu.com

-- fastn.dependency: community/auth
via: amitu.com/github

-- fastn.auth: community/github
mount-point: /github/
config: amitu.com/github-config

You are using auto-import. Auto import is for when you want to use something. You have to be very clear about if you are making the pizza buying the pizza. Main makes pizza and hands it out to others (it can eat the pizza itself as well), but no one can make a pizza.

community/auth is a system (pizza). All systems needs to be configured, and only main package can configure it, and to configure a system you need a module, that needs to be passed by via key.

If main wants to both make pizza and eat pizza, it will pass both auto-import and via keys to a system.

[amitu]

Any module inside slides.fifthtry.com can use auth which will actually use fastn-community.github.io/github? Example:

;; index.ftd file of slides.fifthtry.com

-- ftd.text: $auth.user_id ;; auth auto imported in FASTN.ftd

Yes. Just as I mentioned in earlier comment auth.user-id(), since this needs to perform logic, read cookie etc. We do not use _ in fastn, we use -.

[amitu]

If the answer to above is yes. Shouldn't the FASTN.ftd of slides.fifthtry.com be something like shown below?

Yes. I prefer via instead of provides-via, but yes.

[amitu]

I would love a possible definition of fastn-community.github.io/github's FASTN.ftd and fastn-community.github.io/auth's FASTN.ftd from you (@amitu).

Auth

community/auth/FASTN.ftd

-- import: fastn
-- fastn.package: community/auth
system: community/auth/interface
;; since this module exposes user-id, we want to explicitly pass it
;; to dependencies that we trust.
confidential: true

And community/auth/interface.ftd:

-- optional string user-id():

;; this is the default implementation, only adding because we do not have a syntax 
;; to declare a function without implementing it.
NULL

-- string login-url(next):
string next: /
;; the URL where we should send to to initiate login flow
""

-- boolean is-logged-in():

user-id() != NULL

-- boolean is-anonymous():

user-id() == NULL

This means auth is a system, anyone who implements that system must implement the module pointed by the system key.

Github

community/github/FASTN.ftd

-- import: fastn
-- fastn.package: community/github
auth: community/auth

-- fastn.dependency: community/postgresql-db
auto-import: db

-- fastn.dependency: community/design-system
auto-import: ds

;; this is just a capability, it exposes an opaque token that you must use to 
;; be able to make http requests
-- fastn.dependency: community/http
auto-import: http

community/github/index.ftd (must implement community/auth/interface.ftd):

-- string u:
;; now only people who explicitly ask for http get to make http requests
$processor$: $http.processor 
url: /some/url/

-- optional string user-id():
;; this is the real implementation of user-id function

$u

main package

amitu.com/FASTN.ftd

-- import: fastn
-- fastn.package: amitu.com

-- fastn.dependency: community/postgresql-db
via: amitu.com/db ;; this contains db configs
;; no auto-import as amitu.com does not need db directly
;; it only has to pass it to github

-- fastn.dependency: community/design-system
via: amitu.com/ds ;; this contains color scheme, typography etc
auto-import: ds

-- fastn.dependency: community/http

-- fastn.dependency: community/auth
via: amitu.com/github
;; imposting because index.ftd needs it
auto-import: auth

-- fastn.auth: community/github
mount-point: /github/
config: gh.ftd ;; client secret etc.
;; postgresql-db is also a confidential: true package
postgresql-db: amitu.com/db
;; we have to explicitly pass http because this is also confidential?
;; maybe confidential is not the right key, maybe `explicit: true` is?
;; here we do not have any settings, so we are passing community/http
;; directly.
http: community/http

amitu.com/index.ftd

-- ds.h1: hello logged in user
if: $auth.is-logged-in()

-- ds.button: Login
if: $auth.is-anonymous()
link: $auth.login-url(next=/dashboard/)

[amitu]

The current open questions:

1. why do we have community/auth and fastn.auth? former implies its community driven and anyone can create their version, and later that it is hardcoded in fastn code base. What is rigid and what can change?
2. how do we handle multiple auth providers? do dependencies care? Should we have a user layer?
3. how are user-group definitions communicated from community auth package to fastn?
4. Should we ditch fastn.auth and create a concept of app flavours etc, like we are doing for design system?

[siddhantk232]

-- import: fastn

-- fastn.package: fastn-gh-auth

-- fastn.user-group: test-group
github-starred: fastn-stack/fastn

-- fastn.sitemap:

# Home: /

# About: /about/
readers: test-group

The above is already implemented (a demo is also available here). What we want now is being able to define fastn.user-group headers in .ftd?

-- import: fastn

-- fastn.package: fastn-gh-auth

-- bool github-starred(repo-name): ;; used below in fastn.user-group
string repo-name:

;; get $auth using the `user-details` processor
;; fetch repo stargazers using `http` processor, store it in $repo
;; if $repo.stargazers.include($auth.user.name) then true else false

-- fastn.user-group: test-group
github-starred: fastn-stack/fastn

-- fastn.sitemap:

# Home: /

# About: /about/
readers: test-group

• This is what I think you want @amitu?
• headers in fast.user-group take a function name (defined in FASTN.ftd) and any arguments that will be passed to the function.
• if the function returns zero the group is truthy else falsy
• A group can be composed of multiple such functions. Example:

-- fastn.user-group: starrer-and-siddhant ;; gh user has starred the said repo and has a email: [email protected]
github-starred: fastn-stack/fastn
email: [email protected]

;; How would we do || (OR) configuration with this: Say user has either starred the repo or has a email ending with "@fifthtry.com"?

[amitu]

The above is already implemented.

A lot is implemented, but is not maintained. The task here to first understand the feature, then understand/review the existing implementation, and then eventually make it "pluggable".

-- bool github-starred(repo-name): ;; used below in fastn.user-group
string repo-name:

;; get $auth using the `user-details` processor
;; fetch repo stargazers using `http` processor, store it in $repo
;; if $repo.stargazers.include($auth.user.name) then true else false

-- fastn.user-group: test-group
github-starred: fastn-stack/fastn

This code snippet is if we want to make auth "pluggable" (anyone can implement a new auth system without changing fastn code. Sort of an attempt to answer the question no 3 I raised earlier:

how are user-group definitions communicated from community auth package to fastn?

This is what I think you want @amitu?

It I an attempt but it has question. So far we do not allow functions in FASTN.ftd, is this function supposed to be called at the time of "compilation" (when fastn starts and reads FASTN.ftd for the first time, or at request time? How would the body of the function be like so you can implement arbitrary auth systems?

if the function returns zero the group is truthy else falsy

This is the problem, this means the function is supposed to be called on run time, on every request.

Let's say this is what you had in mind, we have to call each function on run time, is there anything wrong with it? Not really. I was thinking function in FASTN.ftd would be only called on "compile/start" time, but we can relax that requirement, or move the functions to other files. That would be an issue, how do we import them. Never-mind, I think we can resolve all this.

Is it this easy? Are we missing anything?

How would we do || (OR) configuration with this

My understanding what these are OR by default. Maybe we use the operation (OR or AND) an argument when defining groups:

-- fastn.auth-group foo:
$operator$: AND ;; default is OR
github-starred: amitu/import
github-starred: fastn-stack/fastn