We've had some Nintex forms & workflows in production for a few months now in our On Prem SP 2016 farm. I was about to make some modifications to the existing form and am now experiencing an issue where I get prompted for credentials when I attempt to modify a control that is tied to a multi-value look-up column. IE and Edge will prompt me 3 times for credentials then stop, whereas Firefox and Chrome will prompt indefinitely. My account is site collection administrator, so there shouldn't be any permission issues. The only change that I am aware of is that I updated the site column to pull and additional column value, but the issue still occurs if I remove this value. The site is SSL so I can't really take a look at the traffic in a network trace.
Has anyone ran into this issue before? Any suggestions on what to check?
That seems to be an interesting problem
I dont think its caused due to Nintex but I may be wrong. There are a couple of things you might want to check..
1) Did this issue just start appearing? meaning did it prompt from day 1? If not you may be better off to see if there was any changes in the network etc?
2) When you try to put your credentials does it then again go ahead? or is that an access denied? Is there any reference to an external (or internal link secure link-- secure I mean not every one has access to) on your nintex form or the master page etc? ? then may be the browser is opening up the authentication challenge just for that particular link.
3) what is your browser settings for pass through authentication?
4) Zone under which your website is hosted?
Thanks for the response. I'm also doubting that the issue is Nintex, but so far I'm only able to reproduce it with Nintex forms.
1. I just noticed this issue last week when we exported a Nintex form, then imported it to use as a starting point for another content type on the same list. After encountering the issue on the imported form, I checked the original form and was able to reproduce it on that form as well. I've also noticed the behavior on other forms using the same look-up.
2. In IE and Edge browsers it will prompt 3 times and then stop, but according to a Fiddler trace with HTTPS decryption enabled it is still showing a HTTP 401 for <siteurl>/_api/contextinfo. In Chrome and Firefox I will get prompted indefinitely no matter how many times I enter my credentials. There is a hyperlink to a non-sharepoint site on the form, but that link is not tied to any authentication and has been on the form since its been in use since this past summer. We've also have our logo to the form, but that resized in a document library with everyone granted read rights. We're using an out of the box master page. The only branding we've down was through the "change the look" functionality in the out of the box SharePoint interface.
3. My IE pass-through settings are currently set to automatically login to intranet sites. Just now as a test I specifically added this site to the intranet zone and have the same prompting behavior.
4. The site is on our local intranet if you're asking about IE zones. It's in the default zone in in alternate access mappings.
There shouldn't have been any SharePoint updates installed recently either, but I will verify this with our server team.
I took another look at the fiddler trace and think I found why there are issues, but not sure how to fix. In the trace I can see https 401s to https://public.mnstate.edu/HR_Test/_api/contextinfo . The url should actually be https://public.mnstate.edu/sites/HR_Search. The HR_Test is a url that we originally built out on our test farm before moving it to production using migration tool called Metalogix.
The odd thing is that we've been using this for several months without any issues. Also from an end-user perspective everything is still working regarding the workflows/forms for the business process. Issues only come up when attempting to modify the existing forms.
if it has just started appearing and also it now appears on the previous version of the form, suggest that something should have definitely changed.
What happens if you use the same multi-lookup control without the Nintex form (i.e. in default sharepoint form). If the multi-look control is part of the list , do you have an issue if you use the default OOB sharepoint form to enter the data rather than Nintex? just to rule out if its not Nintex.
Can you also remove all the JS out of your Nintex form (your custom functionality might not work) but see if a Nintex form without the JS customisation also errors out?
Can you check both of these?
Sorry Just saw your reply before I posted a reply to your earlier response
please do check both the options I mentioned in the earlier reply.
Can I ask what is this public url? Is it embedded on nintex form? If metalogix has migrated content you can as well change any URL's that you think are not correct on the form and re-publish it?
Thank you for the suggestions. We migrated this site from our test farm this past summer. I'm not actually sure where this HR_Test url is coming from. We have no custom JS script on the form.
The hyperlink on the form I was referring to is http://www.minnstate.edu/system/finance/contracts-purchasing/contracts/reference/index.html . Which I also discovered is incorrect and gives a 404 not found message. I'm waiting for our HR dept. to give an updated link. We have the link inserted into a label control on the form.
There are no issues using the OOB sharepoint forms. I should note that we aren't having any issue submitting data with Nintex forms either, only issues modifying forms.
I think what I'm going to try next is create a new content type using the same site columns and try building out the Nintex form from scratch rather than importing an existing form as a starting point. I'll update the thread later on my results.
I just finished my testing. Here's what I did:
What I found was that despite me deleting the content type, it retained the Nintex form configuration from before. I confirmed that the prompting issue still occurs with the same control. After this, I took the following action:
1. Deleted this content types Nintex form
2. Customized the form again with Nintex (using responsive form) to get a basic layout of a form
I found that after doing this that I was no longer getting prompted when trying to modify the control tied to the multi-value lookup.
So it would seem that the exported form that I initially imported as a starting point is retaining some information from it's original location on our test site.
I opened up the exported form and found some references to HR_Test in the XML of the exported form. So I'm thinking that is the cause of the issue, but i'm not sure if the fix is to simply replace these.
That looks good though .. btw Nintex would anyways keep all its configuration inside its own xml file so deleting the content type & recreating might not really work.
You can try replacing the actual URL in the XML file and see if it works, most probably it should work but again not entirely sure because we are just changing the XML file directly without using the Nintex editor. There is no harm in trying though as you can always keep a backup of your xml file.
best would be if you can find out where in your Nintex form is this URL used? Hidden controls, variables ? Formula etc? and then get rid of it. The URL is the issue and if you dont need it, its best to dig into where its used and remove them rather than changing with a working url.
The reference to HR_TEST is in the xml mark-up for the look-up control that has been giving me prompting issues. Removing/Re-adding the control seems to clear up the issue. My theory on why this happened is that I had exported the form from the HR_TEST site and imported them for use on the production HR_Search site. It would seem that Nintex retains some site information in this scenario. Alternatively it could have been related to our Metalogix Content Matrix migration tool.
My only concern with removing/replacing the control is we have a lot of rules that rely on that control. Do you know if I keep the control named the same if these rules will continue to work? Or would I need to recreate those as well?