Spring Security + OAuth2 with Google

[alfredbrannare]

Description

This PR sets up Spring Security with OAuth2 Google Authentication.

Resolves issue #4

What's included

• SecutiyConfig where only / has .permitAll().
• OAuth2 Authentication with Google.
• CustomOAuth2UserService for future business logic, currently this is where we check if the user exists in the database, if not we save them. Queried by findByProviderAndProviderId(provider, providerId).
• GET /me endpoint for showcasing how the extract information from the AuthenticationPrincipal.
• User entity for saving users to our database:
  • id: Autogenerated UUID
  • name: Extracted from OAuth2UserRequest
  • email: Extracted from OAuth2UserRequest
  • provider: Extracted from OAuth2UserRequest
  • providerId: Extracted from OAuth2UserRequest
  • role: Adds role User as default
  • createdAt: Default LocalDateTime
• UserRepository that extends JpaRepository<User, UUID>.

Testing

AuthenticationIntegrationTest

• Public endpoints return status ok.
• Protected endpoints redirects when not authenticated.
• Protected endpoints work when authenticated.

We tried creating a test for CustomOAuth2Service but we didn't quite get it to work properly so we excluded it. Either the test was green or the application was working, not both at the same time though.

To try this

• Add .env in root with keys provided in Discord
  DO NOT COMMIT ENV FILE
• Start in dev mode
• Visit /me
• Login with Gmail
• Check that it was stored to the DB. /me should also showcase your name, email and id.

Contributors:

• @alfredbrannare
• @Klumpish
• @Emilyempa

Summary by CodeRabbit

Release Notes

• New Features

  • Added OAuth2 authentication with Google login integration
  • Implemented user authentication system with login/logout functionality
  • Added public and authenticated endpoints with automatic redirect to login for unauthorized access

• Tests

  • Added integration tests for authentication flows

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds Google OAuth2 authentication and user management to the backend: new User entity, repository, service to auto-register OAuth2 users, security configuration with OAuth2 login and logout, authentication controller and integration tests, plus related configuration and dependency updates.

Changes

Cohort / File(s)	Summary
Gitignore & Env /.gitignore, backend/.gitignore	Top-level .gitignore now ignores backend/.env and removed .env.local; backend/.gitignore changed target from .env to ../.env (adjusted ignore path).
Application config backend/src/main/resources/application.properties, backend/src/main/resources/application.yml, backend/src/main/resources/application-dev.properties, backend/src/main/resources/application-dev.yml, backend/src/test/resources/application.properties	Added spring.config.import for environment files; switched JPA ddl-auto to update (dev/test); appended createDatabaseIfNotExist=true to DB URL; added Google OAuth2 client registration (client-id/secret from env), dev-profile OAuth2 settings, and test datasource/migration config.
Maven dependencies backend/pom.xml	Replaced/updated dependencies to add Spring Security and OAuth2 client modules, removed/replaced Flyway-related entries, and added spring-security-test for tests.
Domain & Persistence backend/src/main/java/org/fungover/zipp/entity/User.java, backend/src/main/java/org/fungover/zipp/entity/Role.java	New User JPA entity (UUID id, name, email, provider, providerId, role, createdAt, @PrePersist timestamp) and Role enum (USER, ADMIN).
Repository backend/src/main/java/org/fungover/zipp/repository/UserRepository.java	New UserRepository extends JpaRepository< User, UUID > with findByProviderAndProviderId(...) and findUserByEmail(...).
Services backend/src/main/java/org/fungover/zipp/service/UserService.java, backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java	UserService shell with injected UserRepository; CustomOAuth2UserService extends DefaultOAuth2UserService, overrides loadUser to read provider user info and create/save a new User if not present.
Security config backend/src/main/java/org/fungover/zipp/security/SecurityConfig.java	New SecurityConfig defining a SecurityFilterChain: permit /, require auth for others, configure OAuth2 login to use CustomOAuth2UserService, and set logout behavior (invalidate session, delete JSESSIONID, redirect /).
Controller backend/src/main/java/org/fungover/zipp/controller/AuthenticationController.java	New controller with public root endpoint and authenticated /me endpoint extracting OAuth2User attributes (name, email, sub) and returning a greeting string.
Tests backend/src/test/java/org/fungover/zipp/AuthTest/AuthenticationIntegrationTest.java	Integration tests added: unauthenticated /me redirects to login, public / returns 200, authenticated /me returns 200 and contains user name/email using MockMvc and oauth2Login.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant Browser as User / Browser
    participant App as Spring Boot App
    participant Google as Google OAuth2 Provider
    participant Service as CustomOAuth2UserService
    participant Repo as UserRepository
    participant DB as Database

    Browser->>App: Click "Sign in with Google"
    App->>Google: Redirect to Google authorization endpoint
    Google->>Browser: Prompt login & consent
    Browser->>Google: Authorize
    Google->>App: Redirect with authorization code
    App->>Google: Exchange code for access token
    Google->>App: Return access token
    App->>Google: Request userinfo
    Google->>App: Return OAuth2User (sub, email, name)
    App->>Service: loadUser(OAuth2UserRequest)
    Service->>Repo: findByProviderAndProviderId(provider, sub)
    Repo->>DB: SELECT user by provider+providerId
    DB-->>Repo: no match / user row
    Service->>Repo: save(new User(name,email,provider,providerId))
    Repo->>DB: INSERT user
    DB-->>Repo: persisted user
    Service-->>App: return OAuth2User
    App->>App: Establish security context & session
    App->>Browser: Redirect to authenticated endpoint (/me)

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Review SecurityConfig for CSRF/CORS and correct OAuth2 client wiring.
• Inspect CustomOAuth2UserService transactional behavior, duplicate email/provider handling, and attribute extraction robustness.
• Validate User entity UUID generation, role mapping, and @PrePersist timestamp logic.
• Confirm pom.xml dependency changes don't remove required runtime/test transitive deps.
• Check integration test setup and MockMvc oauth2Login expectations.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch issue/4

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b84dc34 and 0e1b33d.

📒 Files selected for processing (1)

• backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🧹 Nitpick comments (11)

backend/src/main/java/org/fungover/zipp/service/UserServiceInterface.java (1)

1-5: Empty UserServiceInterface adds noise without value

This interface has no methods and (from the rest of the PR) doesn’t appear to be used as an abstraction. It’s effectively dead weight right now.

Consider either:

• Removing UserServiceInterface until you have a concrete contract, or
• Defining the expected user-related operations here and having UserService implement it, then injecting the interface in controllers/services.

backend/src/test/resources/application.properties (1)

1-21: Be explicit about Flyway vs ddl-auto=update strategy in tests

You enable Flyway (lines 11–12) and also set spring.jpa.hibernate.ddl-auto=update (line 15). Running both together can cause schema drift or hide migration issues, especially in integration tests.

If you intend Flyway to own schema management, consider switching ddl-auto to validate or none for tests; if you rely on Hibernate’s update for convenience, consider disabling Flyway here instead.

The root/root defaults and local DB URL are consistent with this project’s agreed dev defaults and look fine. Based on learnings, this is acceptable.

backend/src/main/resources/application-dev.yml (1)

1-24: Dev Google OAuth2 config looks reasonable; confirm redirect URI matches console

The dev profile OAuth2 client registration (lines 5–16) is wired as expected: env‑driven client id/secret, profile and email scopes, and an explicit redirect URI.

Please just confirm:

• The redirect URI http://localhost:8080/login/oauth2/code/google is registered in your Google OAuth2 client, and
• You actually want this registration only for the dev profile, given you also configure a google client in application.yml.

backend/src/main/resources/application.yml (1)

1-21: Global Google OAuth2 client config is fine; consider duplication with dev profile

The google client registration here mirrors application-dev.yml, which is good for consistency. With both present, the same client is active for the default profile and the dev profile.

Two minor points to verify:

• That you really want OAuth2 login enabled in both default and dev profiles (or, if not, consolidate config into one place).
• That the redirect URI and scopes here match what you’ve configured in the Google console.

Leaving the provider block commented out is fine if you’re relying on Spring Security’s built‑in Google provider defaults.

backend/src/main/java/org/fungover/zipp/service/UserService.java (1)

1-15: UserService has no API yet; consider inlining or defining its contract

Right now UserService is just a @Service wrapper around UserRepository with no public methods. Combined with the empty UserServiceInterface, this looks like an incomplete abstraction rather than a useful service layer.

Options:

• If you plan to add user-related business logic soon, define the service methods (e.g. “find or create user by OAuth2 principal”) and have UserService implement UserServiceInterface.
• If not, simplify by removing UserService and injecting UserRepository directly until a real service layer is needed.

backend/src/main/java/org/fungover/zipp/repository/UserRepository.java (1)

10-16: Repository methods are fine; clean up stale comment and naming

The repository signature looks good and matches the OAuth2 flow:

• findByProviderAndProviderId is exactly what CustomOAuth2UserService needs.

Minor polish suggestions:

• The comment on line 12 (“change to what ever id we use in User”) seems outdated now that you’ve settled on provider + providerId as the lookup key; consider removing or updating it.
• List<User> findUserByEmail(String email); works with Spring Data’s naming rules, but findByEmail is the more idiomatic convention. Renaming would slightly improve readability if this method is used in multiple places.

backend/src/main/java/org/fungover/zipp/security/SecurityConfig.java (1)

13-17: Make the injected dependency final and consider a clearer name

Since CustomOAuth2UserService is required and injected via the constructor, declaring co2us as final (and optionally renaming to customOAuth2UserService) tightens immutability and makes the intent clearer without behavior change.

backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java (1)

24-43: Guard against missing attributes and consider updating existing users

This implementation assumes Google/OpenID Connect semantics ("sub", "name", "email"), which is fine today but will break or insert invalid data if the provider configuration or scopes change (e.g., missing email) or if you later add another provider. With email marked non‑nullable on the User entity, a null email here will cause a persistence error.

It would be safer to:

• Validate that providerId and email are present and fail fast with a clear exception if not, or
• Relax the DB constraint and handle nulls explicitly, and
• Optionally update existing users’ name/email on subsequent logins so your DB mirrors the latest provider profile.

For example:

 OAuth2User oAuth2User = super.loadUser(userRequest);

 String providerId = oAuth2User.getAttribute("sub");
 String name = oAuth2User.getAttribute("name");
 String email = oAuth2User.getAttribute("email");
 String provider = userRequest.getClientRegistration().getRegistrationId();

-User existing = userRepository.findByProviderAndProviderId(provider, providerId)
-                              .orElse(null);
-
-if (existing == null) {
+User existing = userRepository.findByProviderAndProviderId(provider, providerId)
+                              .orElse(null);
+
+if (existing == null) {
     User newUser = new User();
     newUser.setProvider(provider);
     newUser.setProviderId(providerId);
     newUser.setName(name);
     newUser.setEmail(email);
     userRepository.save(newUser);
-}
+} else {
+    existing.setName(name);
+    existing.setEmail(email);
+    // userRepository.save(existing); // if your JPA setup doesn’t auto‑flush
+}

backend/src/main/java/org/fungover/zipp/controller/AuthenticationController.java (2)

13-21: Remove or use the injected dependencies to avoid dead code

ClientRegistrationRepository, UserService, and UserRepository are injected but never used in this controller. If they’re only for future work, consider dropping them for now (or adding clear TODOs) to reduce noise and keep the constructor focused on what the controller actually needs today.

---

35-41: Prefer OidcUser over raw OAuth2User for Google and fix the response typo

Since this endpoint is Google/OpenID‑Connect specific, using OidcUser would give you typed accessors (e.g., subject, email) instead of relying on magic strings like "sub", "name", "email". It also makes intent clearer and reduces risk if claim names change.

You might also want to fix the typo in the response text ("email adress" → "email address").

For example:

-@GetMapping("/me")
-public String greet(@AuthenticationPrincipal OAuth2User principal) {
-    String name = principal.getAttribute("name");
-    String email = principal.getAttribute("email");
-    String id = principal.getAttribute("sub");
-
-    return "Hello " + name + ", your email adress is: " + email + ", this is your id " + id;
-}
+@GetMapping("/me")
+public String greet(@AuthenticationPrincipal OidcUser principal) {
+    String name = principal.getFullName();
+    String email = principal.getEmail();
+    String id = principal.getSubject();
+
+    return "Hello " + name + ", your email address is: " + email + ", this is your id " + id;
+}

backend/src/main/java/org/fungover/zipp/entity/User.java (1)

10-84: Entity mapping looks solid; any tweaks are mostly modeling choices

The JPA mapping (UUID id, non‑nullable name/email, createdAt via @PrePersist) is consistent and should work well with the OAuth2 user creation flow. If you later need stricter guarantees, you can consider adding uniqueness constraints (e.g., on email or (provider, providerId)) or switching createdAt to Instant for timezone clarity, but there’s nothing blocking here.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 960f8ff and 741200b.

📒 Files selected for processing (16)

• .gitignore (1 hunks)
• backend/.gitignore (1 hunks)
• backend/pom.xml (1 hunks)
• backend/src/main/java/org/fungover/zipp/controller/AuthenticationController.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/entity/User.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/repository/UserRepository.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/security/SecurityConfig.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/service/UserService.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/service/UserServiceInterface.java (1 hunks)
• backend/src/main/resources/application-dev.properties (1 hunks)
• backend/src/main/resources/application-dev.yml (1 hunks)
• backend/src/main/resources/application.properties (2 hunks)
• backend/src/main/resources/application.yml (1 hunks)
• backend/src/test/java/org/fungover/zipp/AuthTest/AuthenticationIntegrationTest.java (1 hunks)
• backend/src/test/resources/application.properties (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-11-26T09:51:20.066Z

Learnt from: alfredbrannare
Repo: fungover/zipp PR: 12
File: docker-compose.yml:6-6
Timestamp: 2025-11-26T09:51:20.066Z
Learning: For the fungover/zipp project, hard-coded development credentials (like MYSQL_ROOT_PASSWORD: root in docker-compose.yml or datasource defaults in application.properties) are intentional development defaults and are not considered security concerns by the project maintainers.

Applied to files:

• backend/src/main/resources/application-dev.properties
• backend/pom.xml
• backend/src/main/resources/application.properties

🧬 Code graph analysis (2)

backend/src/main/java/org/fungover/zipp/service/UserService.java (1)

backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java (1)

• Service (12-48)

backend/src/main/java/org/fungover/zipp/service/CustomOAuth2UserService.java (1)

backend/src/main/java/org/fungover/zipp/service/UserService.java (1)

• Service (7-15)

🔇 Additional comments (6)

backend/.gitignore (1)

36-36: Verify that the ../.env pattern works as intended in Git.

Using ../.env in a subdirectory's .gitignore to ignore a parent directory's file is unconventional and may not work reliably. Git .gitignore patterns are evaluated relative to the .gitignore file's location, and patterns that escape parent directories have limited or inconsistent support across Git versions and clients.

Since the root .gitignore already handles backend/.env (line 8), and .env at the root is handled by line 10 of the root .gitignore, this pattern in backend/.gitignore appears redundant and should likely be removed.

Please verify:

1. Can you confirm the intent of this pattern?
2. Has this been tested to ensure .env files are properly ignored in CI/CD and development workflows?

Suggested fix (if redundant):

### Environment Variables
-../.env
-.env.local
+.env.local

.gitignore (1)

8-9: Clarify .env.local ignore status (inconsistency with AI summary).

The AI-generated summary states that the final state "stops ignoring .env.local", but the annotated code still shows .env.local on line 9, indicating it is being ignored. Please clarify whether .env.local should be ignored or committed to version control.

If .env.local should not be ignored, remove it:

 ### Environment Variables
 backend/.env
-.env.local
 .env

If .env.local should continue to be ignored (current state), the AI summary description is inaccurate and should be disregarded.

backend/src/main/resources/application-dev.properties (1)

6-13: Dev profile setup looks good, but verify .env import scope.

Lines 6 and 13 are appropriate for development (auto-updating schema and importing OAuth2 credentials via .env). However, verify that the .env[.properties] import on Line 13 is intentional when the same import also appears in application.properties (Line 21). If .env is dev-specific, consider removing it from the main application.properties.

backend/src/main/resources/application.properties (1)

6-8: Verify datasource configuration across environments.

Line 6 adds createDatabaseIfNotExist=true to the datasource URL. This is fine for dev/local, but ensure this doesn't inadvertently auto-create databases in production. The setting should ideally be environment-specific or omitted in production if the database is pre-provisioned.

Per learnings, hard-coded dev credentials in application.properties are acceptable for this project, so Lines 7–8 (DB_USER:root, DB_PASSWORD:root defaults) are approved. Based on learnings, hard-coded development credentials are intentional and acceptable for the fungover/zipp project.

backend/pom.xml (1)

79-95: Verify OAuth2 client starter artifactId and dependency alignment

The added dependencies make sense for this PR: security, OAuth2 client, and spring-security-test for your oauth2Login()-based tests.

One thing to double‑check: historically the OAuth2 client starter has been named spring-boot-starter-oauth2-client. Here it’s spring-boot-starter-security-oauth2-client (line 89). If Spring Boot 4.0.0 indeed introduced this new artifact, you’re fine; if not, you may need to switch to the standard artifactId to avoid resolution failures, e.g.:

-            <artifactId>spring-boot-starter-security-oauth2-client</artifactId>
+            <artifactId>spring-boot-starter-oauth2-client</artifactId>

Also ensure your dependency tree doesn’t accidentally pull conflicting security versions when you add both spring-boot-starter-security and the OAuth2 starter.

backend/src/main/java/org/fungover/zipp/security/SecurityConfig.java (1)

22-37: Confirm that default CSRF + session behavior matches your intended clients

The config currently uses the Spring Security defaults for CSRF and session management, which is fine for a browser-based OAuth2 flow but can cause 403s for non-GET requests from SPAs or API clients if you later add such endpoints. Please double‑check that a stateful, session‑based setup with CSRF protection is what you want for this application before you start adding write endpoints.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

# First, let's see the full application.properties file
cat -n backend/src/main/resources/application.properties

Repository: fungover/zipp

Length of output: 735

---

🏁 Script executed:

# Check for environment-specific profile files
fd -H 'application.*properties' backend/src/main/resources/

Repository: fungover/zipp

Length of output: 160

---

🏁 Script executed:

# Search for Flyway configuration
rg -i 'flyway' backend/src/main/resources/ -A 2 -B 2

Repository: fungover/zipp

Length of output: 556

---

🏁 Script executed:

# Check for .env references and imports
rg 'spring.config.import|\.env' backend/src/main/resources/ -A 1 -B 1

Repository: fungover/zipp

Length of output: 362

---

🏁 Script executed:

# Look for any version control history or indication of the original value
git log -n 5 --oneline -- backend/src/main/resources/application.properties 2>/dev/null || echo "No git history available"

Repository: fungover/zipp

Length of output: 120

---

🏁 Script executed:

# Check the application-dev.properties content to see if it overrides DDL-auto
cat -n backend/src/main/resources/application-dev.properties

Repository: fungover/zipp

Length of output: 574

---

Revert DDL-auto to validate in global config and establish proper environment profiles.

Line 15 sets spring.jpa.hibernate.ddl-auto=update globally, which applies to all environments including production. The update mode automatically modifies the database schema at runtime—dangerously unsafe for production. While application-dev.properties (line 6) also declares update, it doesn't override the global value; it only duplicates it. This means production environments will inherit update mode unless an application-prod.properties profile exists to override it.

Additionally, Flyway migrations (lines 11–12) are enabled globally and compete with Hibernate's DDL-auto for schema management. Running both simultaneously undermines Flyway's migration guarantees and can cause schema conflicts. Flyway should have exclusive control over schema changes.

Fix: Move spring.jpa.hibernate.ddl-auto=update from application.properties to application-dev.properties only. Add application-prod.properties with spring.jpa.hibernate.ddl-auto=validate for production safety. Consider disabling Hibernate's DDL-auto entirely (validate or none) and rely solely on Flyway for schema management across all environments.

- spring.jpa.hibernate.ddl-auto=update
+ spring.jpa.hibernate.ddl-auto=validate

Create application-prod.properties with:

spring.config.activate.on-profile=prod
spring.jpa.hibernate.ddl-auto=validate

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	spring.jpa.hibernate.ddl-auto=update
	spring.jpa.hibernate.ddl-auto=validate

🤖 Prompt for AI Agents

In backend/src/main/resources/application.properties around line 15, the global
setting spring.jpa.hibernate.ddl-auto=update is unsafe for production and
conflicts with Flyway; remove this key from application.properties (so Hibernate
DDL-auto is not set globally), add spring.jpa.hibernate.ddl-auto=update only to
application-dev.properties, and create a new application-prod.properties that
activates the prod profile and sets spring.jpa.hibernate.ddl-auto=validate
(spring.config.activate.on-profile=prod and
spring.jpa.hibernate.ddl-auto=validate) so Flyway remains the authoritative
schema manager in production.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

Spring Boot AutoConfigureMockMvc correct import package

💡 Result:

Use:

import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;

Example:

@SpringBootTest
@AutoConfigureMockMvc
class MyTests { /* ... */ }

Sources: [1] Spring Boot reference docs (testing). [2] Spring Boot API (AutoConfigureMockMvc).

---

Fix incorrect AutoConfigureMockMvc import to prevent compilation error

The tests use @AutoConfigureMockMvc, but the imported package path is incorrect:

import org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc;

The correct import is from org.springframework.boot.test.autoconfigure.web.servlet. Update to:

-import org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc;
+import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;

Your three test cases provide good coverage: unauthenticated redirect to login on /me, public access to /, and authenticated user content verification via oauth2Login().

🤖 Prompt for AI Agents

In
backend/src/test/java/org/fungover/zipp/AuthTest/AuthenticationIntegrationTest.java
around lines 1 to 59, the test class imports AutoConfigureMockMvc from the wrong
package
(org.springframework.boot.webmvc.test.autoconfigure.AutoConfigureMockMvc);
replace that import with
org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc so
the annotation resolves correctly, then recompile/run tests to confirm the
compilation error is fixed.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

backend/src/main/java/org/fungover/zipp/entity/User.java (1)

30-32: Default role to avoid nulls against non-null column

Since role is mapped as nullable = false, it’s safer to give it a default (e.g. Role.USER) so new entities aren’t accidentally persisted with a null role if a caller forgets to set it.

Example:

-    @Enumerated(EnumType.STRING)
-    @Column(nullable = false)
-    private Role role;
+    @Enumerated(EnumType.STRING)
+    @Column(nullable = false)
+    private Role role = Role.USER;

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 741200b and b84dc34.

📒 Files selected for processing (2)

• backend/src/main/java/org/fungover/zipp/entity/Role.java (1 hunks)
• backend/src/main/java/org/fungover/zipp/entity/User.java (1 hunks)

🔇 Additional comments (1)

backend/src/main/java/org/fungover/zipp/entity/Role.java (1)

3-6: Role enum looks good as a minimal authority model

Simple USER/ADMIN enum is clear and adequate as a starting point; no issues from an entity perspective.

[EmpyreanMist]

We've implemented this code to be able to build further upon it. It's working great and seems to be no problems.

[Nishune]

I think this code works well and have not found any issues yet. Im working with this branch right now in our own code aswell. Maybe consider adding your work in a package to avoid conflicts?

[Nishune]

As earlier stated i think it looks good and is ready to be merged so we can keep working from this code.