eugenegujing opened a new issue, #7923:
URL: https://github.com/apache/texera/issues/7923
### What happened?
`persistWorkflow` refuses to write to the database on behalf of a guest:
```scala
//
amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowResource.scala:441-444
val user = sessionUser.getUser
if (user == org.apache.texera.web.auth.GuestAuthFilter.GUEST) {
throw new ForbiddenException("Guest user does not have access to db.")
}
```
That branch cannot fire in production. The only thing that would install
`GUEST` as a request principal is `GuestAuthFilter`, and no production code
ever constructs or registers it: every `AuthDynamicFeature` registration in the
repo installs `JwtAuthFilter` instead (`JwtAuth.scala:33-43`,
`AuthFeatures.scala:37`, `NotebookMigrationService.scala:87`), and a
JWT-authenticated user always has a non-null `uid` (`JwtParser.scala:63`
rejects the token otherwise), so it can never equal `GUEST`, whose `uid` is
null. The filter was the authentication layer for the non-user-system mode,
registered behind the `user-sys.enabled` flag; when that mode was dropped in
#3831 the registration went with it, but the filter, the `GUEST` singleton, and
the guard stayed behind.
A repo-wide grep for `GuestAuthFilter` returns hits in only four files: the
filter's own definition, its own unit spec (which builds the filter by hand to
test it in isolation — coverage of the class, not a production path), the guard
above, and one `WorkflowResourceSpec` case that hand-constructs `new
SessionUser(GuestAuthFilter.GUEST)` — an input the production path cannot
produce.
So the repo contains an authentication filter that is dead code, plus a
production guard whose only evidence of working is a test that hand-supplies an
impossible input. Keeping an unregistered `AuthFilter` around is misleading —
it reads as a live authentication path.
A related smell on the same line: `user == GuestAuthFilter.GUEST` compares a
jOOQ-generated POJO with `==`, which in Scala is structural (field-by-field)
equality, not the reference identity that comparing against a singleton
implies. It happens not to misfire today only because `GUEST`'s `uid` is null
and every real user's is not.
### How to reproduce?
Verified by reading and by repo-wide grep, not by running the server:
```
grep -rn 'GuestAuthFilter' . --exclude-dir=node_modules
--exclude-dir=.git --exclude-dir=target
grep -rn 'AuthDynamicFeature' . --exclude-dir=node_modules
--exclude-dir=.git --exclude-dir=target
```
The first returns hits only in the four files above. The second returns only
`JwtAuthFilter` registrations.
### Version/Branch
1.3.0-incubating-SNAPSHOT (main)
### Commit Hash (Optional)
_No response_
### What browsers are you seeing the problem on?
_No response_
### Relevant log output
```shell
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
