Discourse OpenID Connect (OIDC)

תוסף
, , ,
292

Hi @balazsorban44, thanks for the reminder on this. I’ve done a first pass of reviewing the PR. If the author doesn’t have time to work on those things, then it’s likely something we can take on. I agree having PKCE support would be nice.

However, it’s worth noting: I don’t think Discourse is vulnerable to the “authorization code interception” attacks which PKCE protects against. Discourse authentication always happens in-browser over https, and does not use OS-level custom URL schemes which can be intercepted by other apps.

But of course, there is no harm in adding the extra layer of security :+1:

3 לייקים
293

Not necessarily concerned about security.

I addressed the feedback here, keeping the original contributor’s history for credit: feat: PKCE support by balazsorban44 · Pull Request #86 · discourse/discourse-openid-connect · GitHub

Happy to finish the swing on it :slight_smile:

2 לייקים
294

Have you found a solution to this?

295

Unfortunately, no.

296

@swt2c I hacked it into the plugin by adding

  params << ["client_id", "<my-client-id>"]
  params << ["logout_uri", post_logout_redirect] if post_logout_redirect

after the params << ["post_logout_redirect_uri", post_logout_redirect] if post_logout_redirect line in plugin.rb.

Would be great to get official support for this!

298

@balazsorban44 thanks for taking this on! I just merged the PR, so we now have opt-in PKCE support in the plugin :tada:

4 לייקים
299

hey Chris,
how did you integrate Authentik with this plugin. any insights will be helpful. we are struggling since couple of weeks to work it correct.

300

Hmm, I can’t remember something special. What is your problem exactly? Do you want to share some screenshots of your configuration (maybe via PM)?

לייק 1
301

thanks for replying chris. sure. will connect with you later in the week when my dev team is around who was working on authentik. main issues are with the flow and outpost.

לייק 1
304

I have interesting issue, before deploying publicly I want to test that everything works so my OIDC provider is hosted locally (private subnet) and not accessible from internet.
Unfortunately this fails because Discourse doesn’t allow connecting to private IPs.
oidc.example.org resolves to private IP.

OIDC Log: Fetching discovery document from https://oidc.example.org/application/o/discourse/.well-known/openid-configuration
OIDC Log: Fetching discovery document raised error Faraday::ConnectionFailed FinalDestination: all resolved IPs were disallowed
OIDC Log: Discovery document is

---

(oidc) Request phase initiated.
(oidc) Authentication failure! openid_connect_discovery_error: OmniAuth::OpenIDConnect::DiscoveryError, Discovery document is missing

I think because openid_connect_discovery_document can only be changed by Admin it should be trusted and allow even private IPs.

305

There’s a site setting called ‘allowed_internal_hosts’. If you add the internal hostname to that list, then requests to it will be allowed through the SSRF Detector.

In shared hosting services (like the official discourse.org hosting), admins are not trusted to make requests within the hosting environment, so that’s why this protection exists by default.

306

סליחה, אבל אני לא בטוח שאוכל לעקוב אחר ההוראה להוסיף את ההרחבה. אני מריץ את Discour במערכת Docker מקומית שלי, ואני באמת לא מוצא קובץ app.yml כדי להוסיף את ההגדרות.
יכול להיות שזו שאלה טיפשית, אבל יש מדריך להתקנה בסביבת פיתוח מקומית?

307

For a Docker dev environment, try checking under /var/discourse/containers/app.yml?
However, for non-Docker dev installs, see here:

לייק 1
308

The problem is that I can’t find a folder containers

310

Assuming that you followed this guide, perhaps follow this post to install plugins?

312

Hi there.
I added this plugin and it works fine. The problem I see is, our discourse app has aliases, so I can login with 2 urls. Both have been configured in Azure with proper callback urls. I noticed that, the call to https://discourse.company.com/auth/oidc is returning the Location URL with the alias URL, like https://login-blah-bla/authorize?client_id=&redirect_uri=https%3A%2F%[2Fdiscourse.us.company.com](http://2fdiscourse.us.company.com/)%2Fauth%2Foidc%2Fcallback.
Shouldn’t it respect the originated url?

There is an openid_connect_error_redirects but that I believe is for in case of errors. Any idea how I can change the redirect to the authority(aka discourse.company.com).

313

במהלך התקנת חבילת קוד ידנית אתה מקבל את ההודעה הבאה:

e הודעה לאחר ההתקנה מ-oauth2:
e
e התקנת את oauth2 בגרסה 1.4.11, שהיא גרסה שמסיימת את חייה (EOL).
e לא צפויה תמיכה נוספת בסדרת 1.4.x.

והמלצות לשדרוג לגרסה 2 של oauth2.
יהיה הרבה יותר נוח ללא הודעות כאלה, קיימת תוכנית לשדרוג?

אני גם מקבל:
e התקנת את oauth בגרסה 1.1.0, מזל טוב!
e
e התמיכה הלא-מסחרית בסדרה 1.x תסתיים עד אפריל 2025. נא לתכנן שדרוג לגרסה הבאה לפני תאריך זה.
e השינוי שגורם לשברון הלב היחיד יהיה הוצאה של התמיכה ב-Ruby 2.7 ובגרסאות אחרות שגם הן יגיעו ל-EOL לפני כן.

אבל אני מניח שזה לא “אתה”?

314

שלום,
האפשרות Allow new registrations (אפשר רישומים חדשים) נדרשת בהחלט לתפעול התוסף. זה מאפשר ליצור אוטומטית את החשבון בכניסה הראשונה ל-Discourse ומציג כפתור “register” (הרשמה). אבל האם אפשר יהיה לאפשר את השבתתה: כלומר, לא לאפשר למשתמש המתחבר דרך OpenID Connect לשנות את ההגדרות שלו וליצור ישירות את החשבון שלו. זה יאפשר להסיר מהתצוגה את כפתורי ה-“register” (הרשמה) שאין להם מקום בהקשר הזה.
בכבוד רב

315

הצלחת להבין? אני תקוע על אותה הודעה.

316

היי, הצלחת להגדיר את זה? אני לא יודע למה אני תקוע עם זה, מתוך מאות האפליקציות שניהלתי עם OpenID או אימות, דווקא זו עושה לי הכי הרבה בעיות.