Episerver Forms exposes too much platform specific data

Al Higgs

Vote:

Hi all,

We're implementing Forms on a site at the moment, and have had a battle to get it to work both client and server side. It's mostly working now, however in IE8 it just bombs out completely. We're looking into that seperately as our client, who mainly work with the NHS, require support for IE 8 still.

One thing I noticed however was the amount of javascript that Forms injects into the page, that tells the whole world that the website is running on Episerver, see below:

Part of our job as Episerver developers is to harden the site as much as possible, and to try and obfuscate what platform the website is running on - this is basically impossible if you use Forms. We can spend all the time in the world removing certain HTTP Headers, ASP.NET version etc, but at the end of the day that's completely pointless in some ways because Forms now gives the game away.

Can I please suggest that any naming around Episerver forms is just made generic, and that the page Id is encrypted.

Two other points:

1) Is it really necessarry to inject the following comments into every page using Forms:

/*

This EPiServerForms_prerequisite.js TEMPLATE will be compiled with serverside values and injected into ViewMode page

We reuse the existed global var epi from EPiServer CMS, if any. It will init/grab the epi object, and init epi.EPiServer.Forms object

*/

// (by default) Forms's jQuery will be injected right before this file. From now on, we refer Forms own jQuery as $$epiforms.

// after this code, the object $ and jQuery will revert back to its original meaning in original library (Alloy jQuery or other lib).

// Our clients' sites may include their own Jquery version (e.g. a higher version for some special functionalities), which leads to unexpected conflicts with ours.

// To avoid this, we use jQuery.noConflict()  to set up $$epiforms as an allias for our jquery and then, revert Jquery allias to clients' by using

// epi.EPiServer.Forms.OriginalJQuery whose value is set up as Jquery at the beginning in FormBlockController.

// This also allows us to extend our own Jquery's functionalities without causing further conflicts.

2) Why was Forms developed using WebForms when everything else in Episerver is geared towards MVC? Is there a mid/long term plan to switch to MVC? I'm presuming they are currently WebForms as they were pulled from Ektron - would that be correct?

I know Forms is in it's early stages, and it's a huge improvement on XForms, so well done to the team on that. I hope it will continue to improve over time.

Regards,

#172727

Dec 09, 2016 11:23

Thach

Vote:

Hi Al,

Thank you for your feedback. Because your question is quite long, I quote and answer partly.

IE8 is no longer in our official support (of EditView), for CMS in general, and Forms follow the same requirement (in EditView). It's a pity, but I cannot guaranty that Forms work with IE8 because Forms target HTML5 "aware" browsers. If anything we can make your life better, please tell us and I will try to help.

JavaScript : In order to have features beyond standard HTML Form, we need JS for clientside interaction. In case you just don't want it, please opt-out of JS by setting workInNonJSMode="false" in Forms.config (detail guide here). This is at site-level.

"obfuscate what platform the website is running on - this is basically impossible if you use Forms."
I will make this as a feature request and investigate it.
- Basically, we will ship/use the minified version of JS out of the box.
- naming of "Episerver" can be reduced to as little as possible (could you please, suggest something you can satisfy with?)
- page Id is encrypted, yes we will try, though this make other things more complex

Why was Forms developed using WebForms when everything else in Episerver is geared towards MVC?

Forms is not pulled from Ektron. We also said that Forms only supported by MVC-bases website (though developer can make it (rebuild the view template) run in WebForms sites)
So I might misunderstanding your assumption.

And definitely, we're trying our best to improve it over time. For your information, it's in active development mood ;)

Best Regards,
Thach Lockevn.

#173147

Edited, Dec 15, 2016 8:39

Al Higgs

Vote:

Hi Thach,

Thanks for your response.

I understand that Episerver dropped support of IE8/IE9 some time ago, but this was specific to the UI. Only recently (and I suspect around the time of the release of Forms), have Episerver released any guidelines about what browsers are supported for the front-end of the website, which is a shame because Episerver has always done a good job of not injecting itself into, or affecting the front-end. There are lots of Governments, Charities, local councils etc that use Episerver, we have those types of clients ourselves, where upgrading OS and Browsers tend to take a long time, so releasing Forms without that support is a real dissapointment - as it is for WebForms - as officially Episerver supports both WebForms and MVC. We only have 1 client on WebForms, but it was a huge dissapointment to them to find out that it isnt supported in WebForms.

I was mistaken that Forms was taken from WebForms - i guess this was because all the form element views are using .ascx views, which again felt a little odd seeing as Episerver pretty much releases everything in their demo sites using the Razor view engine.

Don't get me wrong, I think Forms is a huge move in the right direction and I applaud the work that has gone into it - hopefully it will continue to improve with haste.

One thing you could do to make our life easier is:

Provide us access to the view that injects the javascript - that way we could put conditional statements around the javascript so it is not included on IE8/9 browsers - it's the javascript that breaks on these versions.
Rather than using Episerver in the naming, just call it Forms - it couldn't be more generic than that.

I hope my comments will be taken on-board.

Regards,

#173371

Dec 22, 2016 11:18

Thach

Vote:

Hi Al,

Forms aims for offering a reference UI that works within given limitations, and assume customers will usually change it or replace it with a different implementation.

I know that big entities that hard to change to new shiny thing because of their strick policy. Let I make it clear, there is no limitation to prevent you doing what you want. And I am here to help you to make it possible.

- Forms aimed to be HTML5 aware, utilize what is good in modern technology. But we can fallback to non-JS - and compatible with old browser. If you need that non-JS feature per-session per-visitor. We can change.

- Forms provides MVC template out of the box, but you can make it work on WebForms project. WebForms support is just not out of the box (sorry about this), it's not impossible, some partners did it, and post solution on World forum.

Form element views are using .ascx views, there are reasons for it. It's might have problem with Razor view when it stay inside a protected zipped nuget module. (we, as developers, personally prefer Razor as well). We try to test all possibilities and take all of those inputs into account, that is decision with the good balance point.

Please be sure that I take all feedbacks and comments here about Form into consideration, it is on-board to investigate ;). Please drop me email (ngocthach.nguyen@youKnowMyCompanyName.com) about your case, (or file a SupportCase) because I might not fully understanding your situation and need more info from your project.

About the naming, I don't think I (as the developer) have enough power ;)

#173373

Edited, Dec 22, 2016 11:45

Thach

Vote:

Hi, after a discusion with Al, we are all clear and I see that what we're doing is still in right direction.

These points are in our plan, even not in long future:

We minified JS (actually it is already minified and included in the package) and use it as default reference. I will recheck about this and update this sentence.
We will create the ability to fallback to a non Js version per visitor (not at site-level only like current situation). AFORM-895
Hiding "Episerver" footprint in JS, CSS, less expose information to malicious user. AFORM-896

This needs more time because of big change to JS API and need decend effort to carefully development and test.
We can't hide all. There is still "Episerver" in some object name or string, because we have component on serverside that has to begin with Episerver C# namespace, and need to match with JS object in clientside context (E.g.: Validator, DependCondition, ...)

Thanks for your feedback.

#173417

Edited, Dec 23, 2016 10:18

Try our conversational search powered by Generative AI!

Episerver Forms exposes too much platform specific data