# 403 error during unit 1 quiz
**URL:**
**Author:**  [@vamshi14krishna](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fvamshi14krishna)%5C
**Post date:** [August 4, 2026, 7:40am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2F403-error-during-unit-1-quiz%2F178448%2F1 "2026-08-04T07:40:21Z")
I am trying to attempt the unit 1 quiz but i am getting below 403 error, even tried the solution mentioned in [AI Agent Unit 1 certification quiz not launching - #7 by Eswar-Kumar](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fai-agent-unit-1-certification-quiz-not-launching%2F142823%2F7) . Please suggest what can i do
---
**Author:**  [@John6666](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2FJohn6666)%5C
**Post date:** [August 4, 2026, 10:06am UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2F403-error-during-unit-1-quiz%2F178448%2F2 "2026-08-04T10:06:45Z")
Hmm… there have been a few OAuth issues lately, but I seem to be able to log in and out of that page normally in my environment:
* * *
From the screenshot, this looks like it is failing **before the quiz itself starts** , while the browser is on Hugging Face’s OAuth/login path. The visible URL is under `huggingface.co/oauth/authorize`, and the page is returning:
> `403 — POST requests must be made from same site.`
So I would not start by changing an access token, token scope, quiz answer, or repository permission. Those would normally matter later; this appears to be failing while establishing the browser login/OAuth session.
I could not reproduce it at the moment:
- On Windows with Chrome, I could sign in to the actual [Unit 1 Quiz](https://huggingface.co/spaces/agents-course/unit_1_quiz) from the normal embedded **App** page.
- I could start the quiz, log out, and sign in again successfully.
- I also tried a fresh minimal OAuth Space using the same Gradio 5.15.0 generation, and sign-in → sign-out → sign-in completed normally.
The quiz currently declares [`sdk_version: 5.15.0` and `hf_oauth: true`](https://huggingface.co/spaces/agents-course/unit_1_quiz/blob/main/README.md), so this suggests that the quiz and Gradio 5.15 OAuth are **not currently failing for every user**.
That does **not** prove that anything is wrong on your side. It still leaves several possibilities: a browser-profile/session problem, an account-specific state, a network/proxy condition, a transient Hub-side failure at the time of the screenshot, or a narrower OAuth regression that only affects some request paths.
## Suggested default route
I would try these in this order:
1. **Close all open quiz and Hugging Face login tabs.**
2. Open the normal [Hugging Face website](https://huggingface.co/) in one ordinary browser window and confirm that the top-right corner shows your avatar rather than **Log In / Sign Up**.
3. In a new tab in that same window, open the [Unit 1 Quiz](https://huggingface.co/spaces/agents-course/unit_1_quiz) and press the login button once.
4. Since you already tried the previously suggested direct link, the next useful comparison is an **extension-free new normal browser profile** , or a different major browser.
5. If it still fails, clear site data only for:
6. If you are actually using a VPN, corporate proxy, managed browser, or filtered school/work network, compare once using another network or device.
A fresh normal browser profile is usually a clearer test than Private/Incognito mode, because private modes may apply different cookie or storage restrictions of their own.
A compact decision tree would be:
```plaintext
Can you log in normally at huggingface.co?
├─ No
│ └─ Treat this as a Hub login/account/browser-session issue,
│ not a quiz issue.
└─ Yes
│
├─ Does the quiz work in a new normal browser profile
│ or another browser?
│ ├─ Yes
│ │ └─ Existing profile, site data, extension, or privacy setting.
│ └─ No
│
├─ Does it work on another network/device?
│ ├─ Yes
│ │ └─ VPN, proxy, managed network, or device policy becomes likely.
│ └─ No
│
└─ Same account fails across clean browsers and networks
└─ Account-specific or Hub-side OAuth path becomes more plausible.
```
Please do not post cookies, access tokens, `Authorization` headers, OAuth `code`/`state` values, or an unreviewed full HAR file publicly.
> **What the screenshot does — and does not — establish**
>
> The screenshot is useful because it places the visible failure on the Hugging Face Hub OAuth page, rather than inside a quiz callback such as **Start** , **Next** , **Submit** , score publishing, or certificate generation.
>
> The standard HF Space login flow is approximately:
>
> ```plaintext
> Quiz Space
> → huggingface.co/oauth/authorize
> → Hub login/authorization
> → Space /login/callback
> → authenticated Space session
>
> ```
>
> The [HF OAuth documentation](https://huggingface.co/docs/hub/spaces-oauth) describes the authorization redirect, callback, and OAuth `state` validation used by Spaces.
>
> In this case, the visible error appears during the Hub-side part of that route. However, the screenshot alone does not tell us:
>
> - the exact POST endpoint that returned the first 403;
> - whether the request included the expected Hub session cookie;
> - what `Origin`, `Referer`, or Fetch Metadata headers were received;
> - whether the browser was already in a partially logged-in state;
> - whether a proxy or extension modified the request;
> - whether the failure was transient.
>
> Also, the wording “same site” should not automatically be read as “third-party cookies are definitely the cause.” A web application may use cookies, request-origin information, CSRF state, or several of these together when deciding whether a POST is acceptable. The public error page does not expose which particular check failed.
> **Why browser, session, and embedding are reasonable checks**
>
> A normal Hugging Face Space page is hosted at:
>
> ```plaintext
> https://huggingface.co/spaces//
>
> ```
>
> but the actual app runs under a separate domain:
>
> ```plaintext
> https://.hf.space/
>
> ```
>
> and is normally embedded into the Hub page.
>
> Hugging Face documents this cross-domain structure in [Cookie limitations in Spaces](https://huggingface.co/docs/hub/spaces-cookie-limitations). Modern browsers can apply different cookie and storage rules to an app inside an iframe than to the same app opened as a top-level page.
>
> The [HF OAuth guide](https://huggingface.co/docs/hub/spaces-oauth) also recommends opening sign-in in a new tab when an app is inside an iframe, because some browsers may otherwise encounter cookie problems.
>
> That makes these comparisons useful:
>
> | Result | What it suggests |
> | --- | --- |
> | Embedded page fails, direct `*.hf.space` works | iframe/cross-site storage boundary |
> | Existing profile fails, fresh profile works | existing site data, extension, privacy setting, or policy |
> | Every browser on one device fails | account, device policy, network, or Hub path |
> | Another network fixes it | VPN, proxy, filtering, or managed network |
> | Normal Hub login also fails | not primarily a Unit 1 Quiz problem |
> | Hub authorization succeeds but the browser later reports Too Many Redirects | a different callback/session branch |
>
> You mentioned that you already tried the direct-Space workaround from the earlier thread, so I would not keep repeating that as the primary solution. Its main remaining value is as one side of an embedded-vs-direct comparison.
> **Related reports, but not proof of the same cause**
>
> There is at least one older HF Forum report with the exact text [`POST requests must be made from same site`](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2Fpost-requests-must-be-made-from-same-site%2F125728). That user encountered it while accepting a gated-model form rather than using a Gradio quiz, and reported that changing browsers resolved it.
>
> That tells us two limited things:
>
> 1. this error text is not unique to the Unit 1 Quiz;
> 2. browser-sensitive Hub POST failures have occurred before.
>
> It does **not** tell us that your case has the same root cause.
>
> There are also OAuth issues involving Spaces and Gradio, but the symptom matters:
>
> - [Gradio issue #8533](https://github.com/gradio-app/gradio/issues/8533) concerned OAuth ending in **Too Many Redirects** , particularly around iframe/cookie behavior.
> - [Gradio issue #13634](https://github.com/gradio-app/gradio/issues/13634) concerns a stale Space session cookie causing an OAuth callback loop even outside the iframe.
>
> Those are useful if your symptom changes into a repeated authorize/callback loop or `ERR_TOO_MANY_REDIRECTS`. They do not directly establish the cause of the explicit Hub-side POST 403 shown here.
>
> A practical distinction is:
>
> ```plaintext
> Explicit 403 on huggingface.co during login/authorize
> → Hub-side browser session / request-context branch
>
> Repeated authorize → callback → authorize redirects
> → Space/Gradio OAuth state and session branch
>
> ```
>
> The two branches are adjacent and could occasionally share an upstream trigger, but they should not be treated as the same bug without the request sequence.
> **Minimal information that would help if it still fails**
>
> If the steps above do not change anything, the most useful report would be a small comparison matrix rather than a large browser log:
>
> | Item | Result |
> | --- | --- |
> | Browser and exact version | |
> | Operating system | |
> | Normal `huggingface.co` login succeeds | Yes / No |
> | Embedded quiz page | Works / 403 / redirect loop |
> | Direct `*.hf.space` page | Works / 403 / redirect loop |
> | Fresh normal browser profile | Works / fails |
> | Different browser | Works / fails |
> | Different network/device | Works / fails / not tested |
> | VPN/proxy/managed browser actually in use | Yes / No / unknown |
> | Approximate failure time and timezone | |
>
> If comfortable using DevTools, open **Network** , enable **Preserve log** , perform one login attempt, and locate the **first** request returning 403.
>
> The non-sensitive fields that would be useful are:
>
> ```plaintext
> Request method
> Host and path
> HTTP status
> Timestamp and timezone
> Request ID / trace ID, if the response provides one
>
> ```
>
> For example, knowing whether the first rejected request is on:
>
> ```plaintext
> huggingface.co/login
> huggingface.co/oauth/authorize
> .hf.space/login/callback
>
> ```
>
> would substantially change the diagnosis.
>
> Before sharing anything, remove or omit:
>
> ```plaintext
> Cookie
> Set-Cookie
> Authorization
> access_token
> refresh_token
> OAuth code
> OAuth state
> client secret
> personal email or IP information
>
> ```
>
> A complete HAR file is usually unnecessary for the first forum reply. The first failing method/path and a request ID are safer and often more useful.
So, for the immediate next step, I would first verify that the same browser window is visibly logged in on the main Hub, then retry from a single fresh tab. If the 403 remains, a new normal browser profile is probably the highest-information, lowest-effort comparison now that the direct-Space workaround has already failed.
---
**Author:**  [@vamshi14krishna](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Fu%2Fvamshi14krishna)%5C
**Post date:** [August 4, 2026, 2:53pm UTC](/static-proxy?url=https%3A%2F%2Fdiscuss.huggingface.co%2Ft%2F403-error-during-unit-1-quiz%2F178448%2F3 "2026-08-04T14:53:08Z")
Thank you it worked when i opened in the incognito.