Potentially dangerous request.path

posted on June 4, 2020

I am trying to use Web Access custom tabs to display forms. I have done this quite a bit and always having to have multiple tabs for processes due to the following reason:

1. Generating the next step URL so that it loads a users task versus a starting form URL.

2. The custom tabs in Web Access still ignore the checkboxes in the configuration in regards to showing on documents or folders (many answers posts about it).

With a new project I'd like to see if I can get an entire process (both starting and any task inside) within one custom tab.

I have my base tab using the forms URL along with the value of a field that is on the template called Test.

In the value of test, workflow is putting in the starting form name and a variable:

When I click on the custom tab I get this error:

However if I take the base URL and copy/past the Test value and hit go in a browser it works.

Do you know why the embedded URL in WebAccess would act differently? Again the plan would then to on form submit update that Test field with different syntax and the resume_ID so the next user in a different can simply use the same tab.

Thanks,

Chris

0 0

replied on June 4, 2020

You can use either the browser debugger tools or the IIS logs on the Forms server to see what request the server is seeing and objecting to. I think the issue arises from the way you are trying to put parameters in variables. Web client will encode variables as necessary - think passing parameters, not building urls. Something like https://example.com/forms/benbill?vendorname=[Test] should be closer to what you want.

0 0

replied on June 4, 2020 • Show version history

Right, but I actually want to build the URL. If I just pass parameters I have to have multiple tabs - one for the starting form and then one for the tasks in the process once the process is started.

So the person would start on a certain tab, but if they were given as task after the process has started they would have to use a different tab that is coded differently with the resume ID.

When I look in debug it looks like it is passing -

https://laserfiche.servername/forms%2Fbenbill%3Fvendorname%3DTest

I can expand more - basically my custom tab URL is going to be one of two things

servername/forms/[formname]?variable=[field]

I am keeping the starting form name as a variable on the field along with other variables for that starting form.

In another tab the URL is:

servername/forms/form/approval/[step]?hideHeader=true

[step] is a field on my form that has the resume_id so that when they click this tab it loads their actual task.

Because I want just one tab I am trying to have the tab URL just be servername/forms/[variable]

That variable would contain one of the two items above (with appropriate items populated from WF)

0 0

replied on June 4, 2020

Hi Chris,

It seems like the issue is that you want only some parts of the parameter to be URL encoded. For now, one way to do this is to make an HTML page on the same server as the Web Client machine, with some JavaScript in it that will read metadata using the webAccessApi. Then, your HTML page can have its own iframe that will serve the appropriate Forms URL.

Below is some sample JS that will look through metadata fields for the selected entry (both on the template and not) for a field with the name "My URL" and log its value to the console. You can then take that parameter, parse it as needed, and pass it to your own iframe.

var metadatafields = [];
metadatafields = metadatafields.concat(window.parent.parent.webAccessApi.getFields().fields.templateFields,window.parent.parent.webAccessApi.getFields().fields.supplementalFields);
console.log(metadatafields.find( myobj => myobj.name === 'My URL').value);

0 0

replied on June 4, 2020

Alright thanks Karina. The goal is to make it a touch easier for users and admin but if we are having to set this up for just a tab that kind of defeats the purpose.

I guess I'll use this as an opporunity to again request Laserfiche fix the custom tab problem in WebAccess in that you have to have both Show in Folder checked and Show in Document checked in order for the tab to be visable.

Also, when you say "only show in folder" that is not what really happens. The tab still shows it just throws an error if you click on it. It would be great if the tab actually didn't show like users want.

As we integration these forms and tabs into more departments the tabs simply grow and the users are forced to look at them an not accidentally click them.

0 0

Discussion

Discussion

Potentially dangerous request.path

Comments 4

Follow-Ups 0

Sign in to reply to this post.