Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce new response headers for world readable/writable realm #999

Merged

Conversation

FadhlanR
Copy link
Contributor

@FadhlanR FadhlanR commented Jan 26, 2024

In this PR, I added new headers X-Realm-Public-Readable and X-Realm-Public-Writable for world readable/writable realm.

*) I'm not sure with world writable realm. Do we need that?

Copy link

github-actions bot commented Jan 26, 2024

Test Results

491 tests  ±0   487 ✔️ ±0   6m 37s ⏱️ +9s
    1 suites ±0       4 💤 ±0 
    1 files   ±0       0 ±0 

Results for commit 03c528f. ± Comparison against base commit d75de62.

This pull request removes 491 and adds 491 tests. Note that renamed tests count towards both.
Chrome 121.0 ‑ Acceptance | Freestyle: smoke check
Chrome 121.0 ‑ Acceptance | basic tests: glimmer-scoped-css smoke test
Chrome 121.0 ‑ Acceptance | basic tests: visiting realm root
Chrome 121.0 ‑ Acceptance | code submode tests: Clicking card in search panel opens card JSON in editor
Chrome 121.0 ‑ Acceptance | code submode tests: can handle error when user puts unidentified domain in card URL bar
Chrome 121.0 ‑ Acceptance | code submode tests: card preview live updates when index changes
Chrome 121.0 ‑ Acceptance | code submode tests: card preview will show in the 3rd column when submode is set to code
Chrome 121.0 ‑ Acceptance | code submode tests: card-catalog does not offer to "create new card" when editing linked fields in code mode
Chrome 121.0 ‑ Acceptance | code submode tests: changes cursor position when selected module declaration is changed
Chrome 121.0 ‑ Acceptance | code submode tests: changes selected module declaration when cursor position is changed
…
Chrome 120.0 ‑ Acceptance | Freestyle: smoke check
Chrome 120.0 ‑ Acceptance | basic tests: glimmer-scoped-css smoke test
Chrome 120.0 ‑ Acceptance | basic tests: visiting realm root
Chrome 120.0 ‑ Acceptance | code submode tests: Clicking card in search panel opens card JSON in editor
Chrome 120.0 ‑ Acceptance | code submode tests: can handle error when user puts unidentified domain in card URL bar
Chrome 120.0 ‑ Acceptance | code submode tests: card preview live updates when index changes
Chrome 120.0 ‑ Acceptance | code submode tests: card preview will show in the 3rd column when submode is set to code
Chrome 120.0 ‑ Acceptance | code submode tests: card-catalog does not offer to "create new card" when editing linked fields in code mode
Chrome 120.0 ‑ Acceptance | code submode tests: changes cursor position when selected module declaration is changed
Chrome 120.0 ‑ Acceptance | code submode tests: changes selected module declaration when cursor position is changed
…
This pull request removes 4 skipped tests and adds 4 skipped tests. Note that renamed tests count towards both.
Chrome 121.0 ‑ Integration | card-editor: can create a specialized a new card to populate a linksTo field
Chrome 121.0 ‑ Integration | operator-mode: can create a specialized a new card to populate a linksTo field
Chrome 121.0 ‑ Integration | operator-mode: can create a specialized a new card to populate a linksToMany field
Chrome 121.0 ‑ Integration | search-index > query: can filter on an array of primitive fields inside a containsMany using 'eq'
Chrome 120.0 ‑ Integration | card-editor: can create a specialized a new card to populate a linksTo field
Chrome 120.0 ‑ Integration | operator-mode: can create a specialized a new card to populate a linksTo field
Chrome 120.0 ‑ Integration | operator-mode: can create a specialized a new card to populate a linksToMany field
Chrome 120.0 ‑ Integration | search-index > query: can filter on an array of primitive fields inside a containsMany using 'eq'

♻️ This comment has been updated with latest results.

Copy link
Contributor

@backspace backspace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestions

as for the question of whether writable is worth having, I can imagine a world-writable realm existing in an intranet-sort of context so it seems good to have to me, but I defer to those who know this more deeply!

assert.true(
response.get('X-realm-public-writable') != undefined,
'realm is public writable',
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would these and below work with assert.ok(response.get('X-realm-public-writable')) instead? It seems a bit more concise to just check for truthiness.

@@ -9,6 +12,8 @@ export function createResponse(
headers: {
...init?.headers,
'X-Boxel-Realm-Url': unresolvedRealmURL,
...(permissions['*'].includes('read') && { 'X-Realm-Public-Readable': 'true' }),
...(permissions['*'].includes('write') && { 'X-Realm-Public-Writable': 'true' }),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we already have X-Boxel-Realm-… maybe these should follow that pattern? X-Boxel-Realm-Public-Readable

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed 👍

Copy link
Contributor

@jurgenwerk jurgenwerk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think passing realm permissions config along so far into response creating functions and having related logic there might not be ideal. I'm leaning towards thinking the logic for telling whether the realm is publicly readable or writable should be the responsibility of the realm itself - I'd consider adding realm.isPubliclyReadable and realm.isPubliclyWritable getters and using that for determining response headers. It would also be a bit easier to refactor once we move to Postgres

@@ -705,30 +715,30 @@ export class Realm {
'7d',
this.#realmSecretSeed,
);
return createResponse(this.url, null, {
return createResponse(this.url, this.isPublicReadable, this.isPublicWritable, null, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that all first three params are properties of realm maybe at this point we can just pass realm and read the needed properties in createResponse?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated db68a7e

@FadhlanR FadhlanR requested a review from jurgenwerk January 29, 2024 14:23
@FadhlanR FadhlanR merged commit 601a893 into main Jan 30, 2024
18 checks passed
@delete-merged-branch delete-merged-branch bot deleted the cs-6535-introduce-response-headers-for-world-readable-writable branch January 30, 2024 10:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants