I’m aware that after_initialize allows us to have access to the loaded properties in SiteSetting but I’m struggling to update my register_middleware method.
Since ruby isn’t my working language it’s more difficult for me to follow.
So in lib/plugin/instance.rb I see this may be responsible for handling the loading of our plugins.
But simplying wrapping my class in after_initialize do … end doesn’t seem to work. (Nothing appears to have loaded at all if I do that).
def register_middleware(omniauth)
omniauth.provider :steam, SiteSetting.discourse_steam_login_api_key || ENV['STEAM_WEB_API_KEY']
end
Is there anything obvious I’m missing?
The problem essentially is that - when register_middleware is called, I don’t think my SiteSetting property is yet loaded.
I’ve set the enabled_site_settings at the top of the file:
Some plugins only use their enabled flag, others add more properties this way. So it’s a little confusing what the purpose of enabled_site_setting is, some clarification on that as well if possible.
I’m hoping this is something relatively simple I’ve overlooked
Hi guys, I’ve uploaded an experimental branch of my plugin in case anyone is able to see what the problem is. The issue is with register_middleware in plugin.rb.
I can’t get access to the SiteSetting variable.
If I do after_initialize { p SiteSetting.discourse_steam_login_api_key } I can see it. But I don’t know how to weave that into register_middleware appropriately.
@eviltrout, I’m having the same issue. I can’t get SiteSetting at a point where it contains the values. If I substitute the SiteSetting variable with a hard-coded string or to use ENV it works perfectly. Is there something @def and I need to do to get SiteSetting to be available here?
Okay, so it seems this may not be the best place to use SiteSetting and might be best to stick to ENV, as now it is capable of reading the SiteSetting, but because it is registered when Discourse starts, it doesn’t and potentially can’t, pick up on changes to the SiteSettings it refers to without stopping and starting Discourse again.
My Steps that seem to indicate this
Installed an oauth plugin using SiteSetting inside register_middleware
Update SiteSettings
Attempt login using ‘with Authenicator’
Get OAuth Bad Parameters error
Stop/Start Discourse
Attempt login
Success!
So unless there is a way to de-register and re-register the middleware, I’m not sure storing this data in SiteSetting is going to help anything. @def, are you seeing similar results?
I haven’t had time to test the changes but from what you’re saying I’m going to assume it will be exactly the same situation for me. Are we implementing this the right way? There’s a lot of other authentication plugins in the mix. I’m wondering if we’re just doing it wrong…
Not 100% sure, but apart from implementing its own strategy, this plugin written by the Discourse Team is attempting to use Saleseforce SiteSettings in its register_middleware
Yeah, actually that does remedy the problem. It does require you to use OAuth2 though (or so it seems), Using OAuth (version 1) doesn’t seem to honor setting options that way. At least I seem to have mine working now properly (still doing some more testing).
You have to restart the app to get it to take the changes (or so it seems) – just confirmed it on my dev machine.
I imagine this is due the lambda being processed at actual runtime later on when the button is actually physically pressed, versus assigned at startup, but this is purely a hunch.
Cool, that is what I suspected. Figured the lambda expression must be delaying the use of the settings to closer to actual run time instead of when the script was started.
Thanks for bringing more attention to this topic @cpradio and thank you for taking a look into this as well @tgxworld, I’ve fixed my plugin now by using a lambda. I made it work with the OmniAuth 1.0 strategy I depend on by modifying it slightly so that it .calls the lambda, and hey presto - the reference to the site setting is preserved.
