Qdabra qRules

Re: Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Mon, 20 Apr 2015 22:11:01 GMT

Hi Hilary,

Good day. Thank you for all your guidance on this. I was able to make it to work using the second option you had provided before. Have a nice day.

Regards,

Rommel Sta. Juana

Re: Impersonation of User using SubmitToSharePointList

Hilary Stoupa — Mon, 20 Apr 2015 21:56:46 GMT

Interesting - this suggests that UDCX should work for a web service connection in a sandboxed form:

https://support.microsoft.com/en-us/kb/981684?wa=wsignin1.0

But then it also says:

the process uses the identity of the account that runs SharePoint Foundation Sandboxed Code Service. The account is specified by the farm administrator. Therefore, the Web authenticates are based on the identity of the SPUCWorkerProcess process.

Which makes me think as long as the sandbox service has access to the list, you could just set useWebServices to true so the form uses the lists connection instead of the SharePoint OM and it will use the account the sandbox service runs under instead.

Re: Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Fri, 17 Apr 2015 00:52:39 GMT

Hi Hilary,

I had try the 2nd option but I get the below error. I guess I need to test option number 1

Failed to submit to SharePoint. URL = '/_vti_bin/lists.asmx'. Exception: Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterException: The remote server returned an error: (401) Unauthorized. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.GetResponseHelper(WebRequest request, DataAdapterCredentials credentials, Stopwatch timer, ExecWebRequestExceptionState state, String adapterName, Boolean isQuery) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) --- End of inner exception stack trace --- at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.HandleExecWebRequestException(Document document, Exception exception, ExecWebRequestExceptionState state, Byte[] exceptionResponse, Ids errorId) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) at Microsoft.Office.InfoPath.Server.SolutionLifetime.DataAdapterWebServiceSubmit.Execute(Document document, Uri soapAction, Uri serviceUrl, XPathNavigator querySubDOM, XPathNavigator resultsSubDOM, XPathNavigator errorsSubDOM, Int64 timeout, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf) at Microsoft.Office.InfoPath.Server.DocumentLifetime.DataAdapterWebServiceSubmit.ExecuteInternal(XPathNavigator queryFields, XPathNavigator resultFields, XPathNavigator errors) at Microsoft.Office.InfoPath.Server.DocumentLifetime.WebServiceConnectionHost.<>c__DisplayClass17.<Execute>b__16() at Microsoft.Office.InfoPath.Server.DocumentLifetime.OMExceptionManager.ExecuteOMCallWithExceptions(OMCall d, ExceptionFilter exceptionFilter) LogId: 5567 Details: System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.GetResponseHelper(WebRequest request, DataAdapterCredentials credentials, Stopwatch timer, ExecWebRequestExceptionState state, String adapterName, Boolean isQuery) at Microsoft.Office.InfoPath.Server.SolutionLifetime.WebServiceHelper.ExecWebRequestSync(XPathNavigator inputSubDOM, Boolean[] inputUseDataset, XPathNavigator resultsSubDOM, Boolean resultUseDataset, XPathNavigator errorsSubDOM, Uri serviceUrl, Uri soapAction, Int64 timeOutMillisec, DataAdapter adapter, Document document, DataAdapterCredentials credentials, Boolean useDcl, Boolean useProxy, Boolean useSelf). Full error node text: No error node text available.

Re: Impersonation of User using SubmitToSharePointList

Hilary Stoupa — Fri, 17 Apr 2015 00:19:19 GMT

Here's a link on setting up a secure store application: https://support.office.com/en-ca/article/Create-or-edit-a-Secure-Store-Target-Application-f724dec2-ce28-4b76-9235-31728dce64b5

Then you'd use the name of that as the value for the /ssoappid parameter in your submit to sharepoint list command. You'd need to inject your form with qRules again, with the option of Admin Deploy selected, and you'd need to publish your template as admin approved - https://www.youtube.com/watch?v=s-gLdnY-oCA

Re: Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Thu, 16 Apr 2015 23:34:02 GMT

Hi Hilary,

Thank you for the confirmation. I will now try the 2nd option and let you know if it works. If not, can you also elaborate the process for option 1.

Regards,

Rommel

Re: Impersonation of User using SubmitToSharePointList

Hilary Stoupa — Thu, 16 Apr 2015 22:48:52 GMT

I know we do have a customer who has used the first option.

Usually, if I'm setting useWebServices to true (that is the right field, by the way) I do that on the QdabraRules finishedLoading node - but you can also just set it right before you run your command. But yes, looks like you understood my rather brief explanation. :)

Re: Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Thu, 16 Apr 2015 22:40:48 GMT

Hi Hilary,

I had now attached the screenshots, sorry.. I will then try this. How about the first option that you had suggested? Have you try it before?

Thank you for all the advise

Regards,

Rommel Sta. Juana

Re: Impersonation of User using SubmitToSharePointList

Hilary Stoupa — Thu, 16 Apr 2015 22:29:12 GMT

Hi - Your screenshots aren't displaying for me - maybe add them under the Options tab as an attachment? Just as an aside - I've not actually tried this, it is more of an educated guess. :)

Re: Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Thu, 16 Apr 2015 22:20:09 GMT

Hi Hilary,

Thank you very much. Just to clarify if I get the 2nd option correct (using UDCX). For the list connection I should convert the below list connection to a UDCX file.

Then once converted, on the UDCX file, I need to enter the user ID and the password that I need to use everytime an update or an item needs to be created on the list?

Finally, on the QdabraRules data source, the below field is the one I need to set to TRUE first before using the SubmitToSharePointList command?

Regards,

Rommel Sta. Juana

Re: Impersonation of User using SubmitToSharePointList

Hilary Stoupa — Thu, 16 Apr 2015 14:10:34 GMT

Hi - it looks like in the Admin Deploy version (if you check that option when you inject the form and then admin deploy the template) there is an undocumented parameter of ssoappid that could be used to include an SSO App ID for submitting under that account.

Another option may be to use UDCX for the lists connection, set the UDCX to use SSO, then make sure (if this is a browser form) to set useWebServices to true in the QdabraRules data source prior to executing the command.

Impersonation of User using SubmitToSharePointList

Rommel Sta. Juana — Thu, 16 Apr 2015 07:37:31 GMT

Hi,

Good day. I'm using Qrules 5.2 and the functionality SubmitToSharePointList. My inquiry is if there is a way to impersonate the user creating or updating the item list. We do want to limit the user who will have access to the SharePoint list where the SubmitToSharePointList creates the list item but we do want everyone to create and edit items in the Sharepoint List but they should not be able to access the list directly.

For example, user A clicks a button on an InfoPath Form. An item should be created in the SharePoint List but not using the account of user A but rather another account (let us say user B which will be the generic account for creating and editing list item on behalf of all the users)

Thank you very much in advance.

Regards,

Rommel