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

feat!: remove properties without access from /access endpoint #6881

Closed
wants to merge 148 commits into from

Conversation

paulpopus
Copy link
Contributor

@paulpopus paulpopus commented Jun 20, 2024

Removes any properties that result in false or an empty object {} from the /api/access endpoint

Improves security by not leaking out names of hidden or private collections

// before
{
  "canAccessAdmin": false,
  "collections": {
    "posts": {
      "fields": {
        "text": {
          "create": {
            "permission": false
          },
          "read": {
            "permission": true
          },
          "update": {
            "permission": false
          },
          "delete": {
            "permission": false
          },
          "readVersions": {
            "permission": false
          }
          // ...

// current
{
  "collections": {
    "posts": {
      "fields": {
        "text": {
          "read": {
            "permission": true
          },
          // ...

@paulpopus paulpopus changed the title feat!: Remove properties without access from /access endpoint feat!: remove properties without access from /access endpoint Jun 20, 2024
@paulpopus
Copy link
Contributor Author

add unit tests

JessChowdhury and others added 23 commits July 24, 2024 10:11
## Description

Adds `loginWithUsername` option to auth config. When set to true, it
will inject an `username` field into the collection config which
replaces the `email` field in the UI. The `email` field is still
required but not unique.

The `username` field can be extended by passing a field named `username`
to your auth collection. Anything added to this field will be combined
with the initial field.

- [X] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

- [X] New feature (non-breaking change which adds functionality)

## Checklist:

- [X] Existing test suite passes locally with my changes

---------

Co-authored-by: Jarrod Flesch <[email protected]>
…elds & config, add generated types for json field (#6984)

- Improves type for `jsonSchema` property of JSON field
- Adds type generation of JSON field with `jsonSchema`
- Adds `typescriptSchema` property to fields that allows you override
default field type generation by providing a JSON schema.
- Adds `typescript.schema` property in payload config, to allow for any
modifications of the type schemas

---------

Co-authored-by: Alessio Gravili <[email protected]>
…#6647)

## Description

Adds the ability to filter by fields within a `group` or **named** `tab`
via the list controls.

Note: added missing translations for the `within` and `intersects`
operator options, these are displayed in the filters for `point` and
`JSON` fields.

- [X] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

- [X] New feature (non-breaking change which adds functionality)

## Checklist:

- [X] Existing test suite passes locally with my changes
)

`req.headers` was missing when admin views fetched data to render. This threads headers through inside of initPage.
… filters in list view (#7044)

Closes #7020

Now supports deeply nested tabs, groups, collapsibles and rows in the
where filters in list view including localised labels.

---------

Co-authored-by: Anders Semb Hermansen <[email protected]>
## Description

- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

- [x] Chore (non-breaking change which does not add functionality)

---------

Co-authored-by: Alessio Gravili <[email protected]>
…assed to Client Document Views (#7026)

**BREAKING:** The minimum required Next.js version has been bumped from
`15.0.0-rc.0` to `15.0.0-canary.53`. This is because the way client
components are represented changed somewhere between those versions, and
it is not feasible to support both versions in our RSC detection logic.
## Description

BREAKING CHANGE: Color values have changed and will have different
contrasts. If you use any of Payload's colors in your apps, you may need
to adjust your use of them to maintain proper styling/accessibility.

Colors palettes changed:
- `--theme-success-*`
- `--theme-error-*`
- `--theme-warning-*`
- `--color-success-*`
- `--color-error-*`
- `--color-warning-*`
- `--color-blue-*`

Updates the color palette used throughout Payload to be more consistent
between dark and light values. Contrast values are now more in line with
the `theme-elevation` contrasts. Some adjustments to the Toast
components as well to match light/dark mode better.

- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

<!-- Please delete options that are not relevant. -->

- [x] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [x] Change to the
[templates](https://github.com/payloadcms/payload/tree/main/templates)
directory (does not affect core functionality)
- [x] Change to the
[examples](https://github.com/payloadcms/payload/tree/main/examples)
directory (does not affect core functionality)

## Checklist:

- [ ] I have added tests that prove my fix is effective or that my
feature works
- [ ] Existing test suite passes locally with my changes
- [ ] I have made corresponding changes to the documentation
paulpopus and others added 25 commits July 24, 2024 10:11
…improving live preview speed (#7201)

Now has a minimum animation time for the autosave but it fires off the
send events sooner to improve the live preview timing.
- When autoLogin is enabled, it will no longer flash an unresponsive
"login" screen. Instead, it will straight up open the admin panel.
That's because, on the server, we will now always & immediately see the
user as authenticated, thus no initial login view is pushed to the
client until the client component sends the auth request anymore. Less
useless requests. Additionally, jwt verification is now completely
skipped
- No more auto-login related frontend code. autoLogin handling has been
removed from the frontend `Auth` component
- less code to maintain, this is way simpler now

**For reviewers:**
- The new logic for autoFill without prefillOnly is here: [jwt auth
strategy](https://github.com/payloadcms/payload/pull/7224/files#diff-7d40839079a8b2abb58233e5904513ab321023a70538229dfaf1dfee067dc8bfR21)
- The new logic for autoFill with prefillOnly is here: [Server Login
View](https://github.com/payloadcms/payload/pull/7224/files#diff-683770104f196196743398a698fbf8987f00e4426ca1c0ace3658d18ab80e82dL72)
=> [Client Login
Form](https://github.com/payloadcms/payload/pull/7224/files#diff-ac3504d3b3b0489455245663649bef9e84477bf0c1185da5a4d3a612450f01eeL20)

**BREAKING**
`autoLogin` without `prefillOnly` set now also affects graphQL/Rest
operations. Only the user specified in `autoLogin` will be returned.
Within the graphQL/Rest/Local API, this should still allow you to
authenticate with a different user, as the autoLogin user is only used
if no token is set.
…ying, type improvements (#7272)

**BREAKING:**
- The `deepMerge` exported from payload now handles more complex data and
is slower. The old, simple deepMerge is now exported as `deepMergeSimple`
- `combineMerge` is no longer exported. You can use
`deepMergeWithCombinedArrays` instead
- The behavior of the exported `deepCopyObject` and `isPlainObject` may
be different and more reliable, as the underlying algorithm has changed
We do not really need runtime joi schema validation - this is what TypeScript is for. If people are ignoring TypeScript errors in your schema, or JavaScript errors, that is their fault and does not warrant an extra dependency (joi), lots of code to maintain, as well as slower startups.

If we wanna keep runtime schema validation, we should switch to zod so that we can generate TypeScript types based on the schema and do not have to manually maintain config properties in 2 different places (types & schema).

**joi PROs:**
- Safety for JavaScript-only evangelists messing up their schema
- Safety for people putting @ts-expect-error or `as any` everywhere in their code

**joi CONs:**
- Larger bundle size
- More Modules
- Slower Compilation Speed in dev. Worse DX
- Slower Startup (it needs to validate) in dev. Worse DX
- More code to maintain. For every schema change we'll have to change the types AND the joi schema
- TypeScript already throws proper errors if you mess up your schema. Why have runtime errors?
- The errors are bad. They might tell you what field has an issue, but they do not tell you what exactly is wrong. You have probably seen those "Field XY, value is incorrect" errors - and value could mean anything. Worse DX
- Having extra properties in your schema, even if they are useless, doesn't cause any harm

Cons outweigh the pros
…lates and core (#7283)

Some package.json's were on older or mismatching Next.js / React
versions. This includes other Next.js packages like @next/env
Doesn't look like those hacky esm-cjs imports are needed anymore.

These major pino releases only drop Node.js version support for versions
which payload doesn't support anyways.
…7297)

Adjust logic for determining package manager. Needed to move command
exists logic to be evaluated only after other possibilities were
exhausted.

Closes #7290
…al chars in sort (#7294)

## Description

V2 PR [here](#6923)

- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

- [x] Bug fix (non-breaking change which fixes an issue)

## Checklist:

- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] Existing test suite passes locally with my changes
## Description

The first version document throws an error because `latestPublished` and
`latestDraft` are undefined.

- [X] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.

## Type of change

- [X] Bug fix (non-breaking change which fixes an issue)

## Checklist:

- [X] Existing test suite passes locally with my changes
- improves types
- fixes create-first-user fields
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet