You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have created a Microsoft social connection using the Connection resource with the windowslive strategy. Every time I run pulumi up this resource thinks it needs updating, even when nothing has changed.
Update: actually, they are not supported at all due to a lack of support upstream, see my edits below
Expected behavior
No changes should show when running pulumi up if the provider options did not change.
Current behavior
Changes show when running pulumi up, even though the provider options did not change:
Previewing update (stack)
View Live: [xxx]
Type Name Plan Info
pulumi:pulumi:Stack my-stack
~ ├─ auth0:index:Connection google-connection update [diff: ~options]
~ └─ auth0:index:Connection microsoft-connection update [diff: ~options]
Resources:
~ 2 to update
42 unchanged
Closer inspection shows that the provider seems to be removing the fields from the options parameter, which is why it thinks it is different:
I had a similar problem with the Google connection, where it kept adding scopes, which that was fixable by adding the same scopes myself. But how can I work around it if it's removing fields? I need to provide the client credentials somehow.
It happens with fixed strings as well as config items.
Context (Environment)
pulumi version: v2.20.0 @pulumi/auth0: "^1.8.0"
UPDATE: I then realised that the resulting social provider has a warning triangle saying that it is using Auth0's keys, so clearly it is removing my credentials entirely, which is consistent with the issue. So the question is - what parameters should I use? If I create a connection manually and inspect it via the management API, it clearly shows that the clientId and clientSecret fields are set:
So this still appears to be a bug. The clientId and clientSecret are getting thrown away when I create the connection.
UPDATE 2: I appear to have found the source of the problem, which is a lack of support upstream. Sorry for the noise on this repo, I guess it relies on a suitable fix in the Terraform provider before this will work.
The text was updated successfully, but these errors were encountered:
roblframpton
changed the title
windowslive social connection always needs updating even when there are no changeswindowslive social connection are not supported
Feb 17, 2021
I have created a Microsoft social connection using the
Connection
resource with thewindowslive
strategy. Every time I runpulumi up
this resource thinks it needs updating, even when nothing has changed.Update: actually, they are not supported at all due to a lack of support upstream, see my edits below
Expected behavior
No changes should show when running
pulumi up
if the provider options did not change.Current behavior
Changes show when running
pulumi up
, even though the provider options did not change:Closer inspection shows that the provider seems to be removing the fields from the options parameter, which is why it thinks it is different:
I had a similar problem with the Google connection, where it kept adding scopes, which that was fixable by adding the same scopes myself. But how can I work around it if it's removing fields? I need to provide the client credentials somehow.
Steps to reproduce
Create a resource such as:
It happens with fixed strings as well as config items.
Context (Environment)
pulumi version
: v2.20.0@pulumi/auth0: "^1.8.0"
UPDATE: I then realised that the resulting social provider has a warning triangle saying that it is using Auth0's keys, so clearly it is removing my credentials entirely, which is consistent with the issue. So the question is - what parameters should I use? If I create a connection manually and inspect it via the management API, it clearly shows that the
clientId
andclientSecret
fields are set:So this still appears to be a bug. The
clientId
andclientSecret
are getting thrown away when I create the connection.UPDATE 2: I appear to have found the source of the problem, which is a lack of support upstream. Sorry for the noise on this repo, I guess it relies on a suitable fix in the Terraform provider before this will work.
The text was updated successfully, but these errors were encountered: