'
```
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 4, 2016, 3:18am UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/6 "2016-07-04T03:18:21Z")
Fixed in
[https://github.com/discourse/discourse/commit/0ffe8402a9f2f1a7cc4ced1abf1f21fd8f93578b](https://github.com/discourse/discourse/commit/0ffe8402a9f2f1a7cc4ced1abf1f21fd8f93578b)
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 4, 2016, 1:14pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/7 "2016-07-04T13:14:33Z")
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?
---
### Author:  [@def](https://meta.discourse.org/u/def)
#### Post date: [July 4, 2016, 4:45pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/8 "2016-07-04T16:45:49Z")
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_…
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 4, 2016, 4:49pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/9 "2016-07-04T16:49:16Z")
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
>
---
### Author:  [@def](https://meta.discourse.org/u/def)
#### Post date: [July 4, 2016, 5:46pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/10 "2016-07-04T17:46:55Z")
Is there something about the use of a lambda that preserves the reference to the `SiteSetting` then(?)
Example from `facebook_authenticator.rb`:
```
class Auth::FacebookAuthenticator < Auth::Authenticator
def register_middleware(omniauth)
omniauth.provider :facebook,
:setup => lambda { |env|
strategy = env["omniauth.strategy"]
strategy.options[:client_id] = SiteSetting.facebook_app_id
strategy.options[:client_secret] = SiteSetting.facebook_app_secret
},
:scope => "email"
end
end
```
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 4, 2016, 7:11pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/11 "2016-07-04T19:11:51Z")
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).
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 4, 2016, 9:02pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/12 "2016-07-04T21:02:28Z")
Is your code some where I can look at?
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 4, 2016, 9:11pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/13 "2016-07-04T21:11:48Z")
Yeah, it is at [GitHub - discourse/discourse-linkedin-auth: LinkedIn OAuth Login support for Discourse · GitHub](https://github.com/cpradio/discourse-plugin-linkedin-auth) (or at least the final version is now there)
Without using the lambda, it doesn’t reload the SiteSettings without a server restart. So if you replace the lambda with
```plaintext
SiteSetting.linkedin_client_id,
SiteSetting.linkedin_secret
```
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.
---
### Author:  [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [July 4, 2016, 9:20pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/14 "2016-07-04T21:20:39Z")
> [@cpradio](#):
>
> Without using the lambda, it doesn’t reload the SiteSettings without a server restart. So if you replace the lambda with
Yup that is the right behavior. Settings configured in the initializers will require an app reload to be updated.
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [July 4, 2016, 9:22pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/15 "2016-07-04T21:22:06Z")
> [@tgxworld](#):
>
> Yup that is the right behavior. Settings configured in the initializers will require an app reload to be updated.
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. 🙂
---
### Author:  [@def](https://meta.discourse.org/u/def)
#### Post date: [July 8, 2016, 9:33pm UTC](https://meta.discourse.org/t/loading-our-sitesetting-properties-before-plugin-loads/45572/16 "2016-07-08T21:33:32Z")
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 `.call`s the lambda, and hey presto - the reference to the site setting is preserved.