You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Feature Request: Separate Web Client & Web Client Configuration into Separate IIS Applications

posted on May 18, 2021

Currently, if you enable SSO (LFDSSTS) for the Web Client. then reaching the Web Client Configuration page also redirects you to the LFDSSTS page. LFDS does not control who does/doesn't have access to Web Client Configuration, but you have to have SOME credentials that exist in LFDS to get past this page (testing confirmed that ANY credentials in LFDS will work; licensed/unlicensed, etc.).

 

This, among other reasons, prompts this request... why not separate Web Client & Web Client Configuration into separate IIS Applications? If that were the case, applying SSO to the Web Client wouldn't also apply it to Web Client Configuration.

 

This approach would be the same one that's currently taken for Forms, for example. Forms and FormsConfig are separate IIS Applications; though they run under the same App Pool (FormsAppPool), but the result is, when you turn on LFDSSTS Authentication for Forms, it doesn't apply to reaching the FormsConfig page (you don't redirect to LFDSSTS when trying to hit the FormsConfig page).

This is also the approach taken with LFDS and LFDSSTS; they are separate IIS Applications.

However, currently, the Web Client Configuration page is just a subdirectory of the Web Client application:

  • Web Client:   /Laserfiche
  • Web Client Configuration:   /Laserfiche/Configuration/Configuration.aspx


Why not separate them:

  • Web Client:   /Laserfiche
  • Web Client Configuration:   /LaserficheConfig

(or "/LFConfig", or "/WAConfig", or something similar)

They could both still run under the "WebAccessAppPool", but they would be separate IIS Applications, running in separate application domains.

 

I'm creating this as a Feature Request for future releases of Laserfiche Web Client.

4 0
replied on May 18, 2021

Can you clarify what you see as the benefit? Just that your SSO settings wouldn't apply to both?

0 0
replied on May 20, 2021

Brian- 

That is the first major impact I see at this time. Being that access to the Configuration page isn't controlled by LFDS at all, it doesn't make sense to challenge-for, and be required to enter, those credentials, even when the actual Web Client (repository access) is utilizing SSO.

Also, I believe that Web Client may the ONLY remaining Laserfiche web application that has a single IIS Application that contains both the client application and configuration page (Forms, WebLink, & Audit Trail all have separate IIS Applications for their respective config/designer pages).

From a pure web server administration perspective, these two pages (Client & Configuration) have two completely different functions and different access control methodologies. As such, it would make sense to run them under separate applications in IIS with their own application domain space, respectively. 

I suppose it really begs the question... what is the benefit of keeping them together under the same IIS Application?

3 0
replied on May 21, 2021

To be pedantic, any work to change the structure of the application is effort not available for other improvements in the software. So one benefit to keeping them under a single application is that maintaining the status quo lets us work on other items. Which isn't to say that the change you are proposing doesn't have benefits, it's just to emphasize that nothing is free and we need to weigh the costs of a change against benefits.

All that said, I do appreciate your real-world experience with the system that we sometimes lack. Getting back to the concrete benefits, I read you as saying that you never want to use SSO to access the configuration page and always want to use Windows authentication. Or is there more you mean by "different access control methodologies"? If that could be done within a single IIS application, do you see other reasons for separate applications?

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.