Setup your list to Initialized with Filter based on the credentials of the Authenticated User, this way nobody will modify the running time params to try to retrieve some other data since the filter will always run that from the List View directly and is not expecting any other parse data. regardless of Malicious Users or not =)

Tipically I create a SQL SMO for UserRoles and here I can put an Admin, User or Auditor, when the form start execute the query to capture the role. based on the role and the authenticated user will initialize the view. and will be using those params.... since the list view will parse the role and the user that is what is used in the list to filter and display.

Good Luck !!!

Hi K2CaveMen,

Thanks for your reply.

I have modified my Initalize rule so when it executes List, as well as passing the parameter in the Input Mapping I have also added a Filter which filters on the 'UserFQN' field in my SmartObject, using the value Current User / FQN from the Context Browser.

 This just means that the call to Ajaxcall.ashx has got the logged-in user's name in twice, once as a parameter and again as a filter. I can still modify both of these using Fiddler and run the web service call with another user's login. I then get that user's details (not in the actual list view, you understand, but in the XML response from the web service).

If the list run the filter from Initialize based on the Environment authenticated user, regardless of whatever you inject in the URL, how will that be changed by Fiddler.

I have K2 as service account and always return the correct recods.

Additionally you can add an outbound previous rule that only certain users can execute and this can limit only to specific users to be granted to the List if you are not part of the chosen list rediret to a 404 because is considrered un-trusted, and if you are part of the list let the filter show only the entries he is part or access is granted. again regardless of whatever you inject in the URL with Fiddler, CURL or some other script tool.

Hope this helps !!!.

"If the list run the filter from Initialize based on the Environment authenticated user, regardless of whatever you inject in the URL, how will that be changed by Fiddler"

 Because when the form loads, the authenticated user is evaluated, and then a client side web service call happens which passes the username back to the K2 web service Ajaxcall.ashx.

With Fiddler we can replay that web service call using a different value for the username parameter, and see all the returned data for the other user.

So, we are not injecting into the form/view URL but modifying the request header in the subsequent call to the web service.

Hi Nagorskiy, thanks for your reply.

The logged-in user is using an external user manager based on a table of users in a SQL database, so these are not Windows users. The external user accounts are created via a web form which just adds them to the table of users. I don't think impersonation will work in this case, will it? The user needs to have a type of credential that SQL Server understands, and the user will need permission to log on to SQL server. Is that right, the solution will need re-architecting to support RLS?

Just to clarify the situation with this patch for SQL broker which enable SQL SI to work under K2 service account context, but for every query set CONTEXT_INFO to impersonated user, we now have this OOB:

- In K2 4.7, with K2 4.7 August 2017 Cumulative Update FP13 (https://help.k2.com/kb002081) and newer

- In K2 Five with FP1 (https://help.k2.com/kb002108) and newer