Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

EA consent: `prompt=consent` forces "Need admin approval" in tenants where an admin already granted consent

Closed
  • Is something wrong?
#6,082 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
authentication

Research direction

Start with EaGraphAuth.cs and EaConsentController.cs, then review the existing consent-flow behavior and tests around BuildConsentUrl and Callback. Add tests for the four listed outcomes, including logging error_description, and verify redirects distinguish connected from failed; the URL builder should no longer include a prompt= parameter.

Written by the indexing model from the issue text.

Description

area:ai bug sev:H

Repository and prior art

  • The defect is in memex/Memex.Portal.Shared/Authentication/EaGraphAuth.cs and EaConsentController.cs. Both files are in MeshWeaver core.
  • Pull request #2101 made /auth/ea/connect skip consent for a connected user. It kept prompt=consent for the first connect.
  • No issue covers the admin-consent case. Searched across Systemorph repositories for prompt=consent, auth/ea/connect and EA consent callback.

What happens

On a customer instance, a member of the customer's Entra tenant opens /auth/ea/connect:

  1. Microsoft shows "request access" (admin approval).
  2. The tenant admin approves the request.
  3. The user retries, and Microsoft shows "request access" again.

Cause

EaGraphAuth.BuildConsentUrl appends &prompt=consent (EaGraphAuth.cs:142). This forces the consent dialog on every authorize request. In a tenant where users may not consent to these scopes, the forced dialog always becomes an admin-approval request. This also happens after an admin granted tenant-wide consent.

Evidence: on 2026-10-02, prompt=consent was removed by hand from the authorize URL. Microsoft then skipped the approval page and redirected back to the portal.

Second defect: the callback hides its outcome

EaConsentController.Callback redirects to the return URL in every case: success, Microsoft error and failed code exchange. The browser shows no result. The log line keeps error but drops error_description. Diagnosis on the instance therefore needed the portal logs.

Proposed change

  1. Remove &prompt=consent from BuildConsentUrl. Microsoft still prompts when consent is missing (incremental consent). ?force=true still runs the authorize flow and stores a new grant.
  2. Log error_description in the callback.
  3. Report the outcome on the return URL: eaConnect=connected, or eaConnect=failed&reason=<class>.
  4. Update the comments that name prompt=consent (EaConsentController.cs:92, EaGraphAuth.cs:136).

Tests (write first)

  1. BuildConsentUrl contains no prompt= parameter.
  2. A callback with error redirects with eaConnect=failed and logs error_description.
  3. A callback whose code exchange fails redirects with eaConnect=failed.
  4. A callback whose code exchange succeeds redirects with eaConnect=connected.

Severity sev:H: members of a tenant that restricts user consent cannot connect the EA at all.

Dominant language
C#
Stars
12
Forks
5
Avg merge
6h 30m
Merged PRs (30d)
960

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Systemorph/MeshWeaver

All issues in Systemorph/MeshWeaver

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.