cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

WFM 2019 - Broken fileshare path

We integrate our AppBroker 2020 R1 with Workflow Manager 2019 to auto create workflows. It was brought to my attention that many special characters seem to "break" the workflow share path when getting auto created - so if someone submits an AB request with a Brazilian character, for instance, it seems this messes up the auto creation of our sharepath and not link it properly to the workflow. The best way to fix at this time is to create a new request and remove the special character before it hits WFM, when still in AB. Is there any list of special characters Flexera has that have been reported to cause such issue? My one team member thought our previous tech support had a list from Flexera of special characters to avoid using. Any tips on this would be much appreciated! 

(2) Replies
CharlesW
By Level 12 Flexeran
Level 12 Flexeran

Generally, we don't run into too many problems with "special" characters within App Broker.. When we do, it is usually when the user enters characters in question responses, which IIS determines can be used for XSS attacks.. These would be usually be <> followed by another character. The following was a pretty good writeup on the subject:

https://infosecauditor.wordpress.com/2013/05/27/bypassing-asp-net-validaterequest-for-script-injection-attacks/

I'd be inclined to think that the problem may be on the Workflow Manager side of things.. I really don't know anything about Workflow Manager... What is this "Fileshare path" to which you refer? Is it simply a path, such as c:\windows\system32? If so, then I'd guess that you would be limited to windows directory naming restrictions.. 

@CharlesW - Thanks for the response. We use answers from AppBroker requests and push the data to Workflow Manager (ex: Application/Software Name) to help auto create workflows. I agree - what you said got me thinking that it would be worth pulling up list of special characters that aren't allowed with Windows file explorer as it could be this is where the corruption is happening. Thanks for the below link; this is really helpful. We are reviewing ServiceNow integration with WFM directly and trying to see if we can improve this issue today to possibly implement error validation on ServiceNow form to avoid pushing to WFM and breaking folder name.