# \[IGN-14158\] Bug in 8.3 with "temp" user source

**URL:** <https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350>\
**Category:** Ignition 8.3 Early Access\
**Created:** [September 3, 2025, 7:47am UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350 "2025-09-03T07:47:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![diamond](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@diamond](https://forum.inductiveautomation.com/u/diamond)\
**Post date:** [September 3, 2025, 7:47am UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350/1 "2025-09-03T07:47:22Z")

</div>

1. Reset password with gwcmd -p

2. Set **Designer Authentication Strategy** to **Identity Provider** (we have SAML)

3. Delete Ignition’s created “temp” source.

4. Change any param in /app/platform/security/settings, such as “Gateway audit profile”.

This is because **Designer Authentication Strategy \>**  **Classic mode** has “temp” user souce selected.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/9/f93d08e430505304a63fb56291076479ef98f6ba.png)

Note that this error appears when having “Identity Provider” mode selected, which does not require that field.

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/3/a/3abea2ef1dea1f9f1cf36bc6182bbd94193e3ea0.png)

Regards!

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [September 3, 2025, 11:39am UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350/2 "2025-09-03T11:39:04Z")

</div>

The designer authentication strategy is different than the system user source for editing the gateway configuration. This is not what's used to make gateway configuration changes which is what you're trying to do.

The real bug is that it shouldn't let you delete a user source that is still being used.

---

<div class="post-metadata">

**Author:** ![diamond](https://avatars.discourse-cdn.com/v4/letter/d/e79b87/32.png) [@diamond](https://forum.inductiveautomation.com/u/diamond)\
**Post date:** [September 3, 2025, 11:52am UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350/3 "2025-09-03T11:52:37Z")

</div>

Yes, it’s an option too. A warning is displayed but its not very explainatory.

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [September 3, 2025, 12:57pm UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350/4 "2025-09-03T12:57:03Z")

</div>

> [@michael.flagler](#):
>
> The real bug is that it shouldn't let you delete a user source that is still being used.

Not quite.

There are scenarios where it could be important to allow for forceful deletion of a resource, though in most of those scenarios it is highly likely a user would then be “replacing” the resource they just deleted.

A “standard” attempt at deleting a resource which is referenced by some other system will actually successfully fail by providing a `200` response (request was received and recognized as valid) with a `success` value of `false`. That same response will include a list of resources which contain references to the resource you tried to delete, and you must re-try the original request with a `confirm` query param of `true` in order to complete the deletion.

So we do try to prevent accidental removal of important resources by forcing a speed-bump of sorts.

Request and response when trying to delete the `default` User Source from a vanilla deployment:

```python
<gateway>/data/api/v1/resources/ignition/user-source/default/b07e9ce2536f7bf30e4c20896afabf21a0443bc7ef43de087cbac183dec60a11?confirm=false&collection=core

```

```python
{
  "success": false,
  "changes": [],
  "problem": null,
  "references": [
    {
      "type": "ignition/security-properties",
      "name": "security-properties",
      "property": "SystemAuthProfile"
    }
  ]
}

```

Note the `confirm=false` query param the page is sending. The response would actually be the same without that param, but the point is that the flag exists at all. Setting that value to `true` - which is performed in the UI by confirming the action - is going to lead to undesirable behaviors.

 ![Screenshot 2025-09-03 at 5.55.29 AM](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/5/6529704c26b18441a4cda15202ff224aecbe7208.png)

---

<div class="post-metadata">

**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\
**Post date:** [September 3, 2025, 1:02pm UTC](https://forum.inductiveautomation.com/t/ign-14158-bug-in-8-3-with-temp-user-source/110350/5 "2025-09-03T13:02:30Z")

</div>

There are only two bugs I see in this scenario:

1. There is no UI indication that a component is failing validation checks when the field is not displayed due to being unused. I’ll open a new ticket to get this fixed, though there’s no chance of it making the 8.3.0 release.
2. the trailing ` 1` at the end of the validation warning/error. I’d actually encountered that earlier today and have already opened that ticket - though it’s an extremely low priority.