feat: add standalone pronote ui demo - #3
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting
| const onSubmit = async (event: FormEvent) => { | ||
| event.preventDefault(); | ||
| const res = await fetch('http://localhost:4000/auth/login', { | ||
| method: 'POST', | ||
| headers: { 'Content-Type': 'application/json' }, | ||
| body: JSON.stringify({ email, password }), | ||
| }); |
There was a problem hiding this comment.
The login page posts credentials to http://localhost:4000/auth/login directly. This works only when the API is reachable on the developer’s machine at that exact host and port. The rest of the web app already uses an API_URL env variable, so deployments where the backend is on another domain/port (Docker, staging, production) will fail to authenticate. Consider reading the same API_URL env value as dashboard/page.tsx or a NEXT_PUBLIC_* variable instead of hard‑coding the URL.
Useful? React with 👍 / 👎.
| import { Controller, Get, Query, UseGuards } from '@nestjs/common'; | ||
| import { DashboardService } from './dashboard.service'; | ||
| import { JwtAuthGuard } from '../../common/guards/jwt-auth.guard'; | ||
|
|
||
| @Controller('dashboard') | ||
| @UseGuards(JwtAuthGuard) | ||
| export class DashboardController { | ||
| constructor(private readonly dashboardService: DashboardService) {} | ||
|
|
||
| @Get() | ||
| getDashboard(@Query('role') role = 'ELEVE') { | ||
| return this.dashboardService.getDashboardForRole(role); | ||
| } |
There was a problem hiding this comment.
The dashboard endpoint accepts a role query parameter and forwards it directly to DashboardService.getDashboardForRole while the guard only checks that an Authorization header exists. Any caller can therefore request ?role=ADMIN to obtain privileged widgets regardless of their authenticated role. This effectively bypasses the role‑based access control and will leak data once real dashboard content is wired up. The controller should derive the role from the authenticated user (e.g. request.user.role) and/or enforce a RolesGuard instead of trusting a query parameter.
Useful? React with 👍 / 👎.
1 participant
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_68dc28a98ffc83298dc7428b4c2d8710