potree | WebGL point cloud viewer for large datasets | Image Editing library

After a few hours spent investigating and trying, I have come up with a solution. The principle behind it is the same as a digital clock.

Here's the code:

I initialize my potree-core as follow, maybe gives you a clue:

I tried different methods to solve this issue. Finally, i have arrived at a solution. (May be it is not the best but could be helpful to someone who also has similar issue).

WORK FLOW: Now, we receive several built webpages from our external sub contractors every week. Our subcontractors use Potree Converter to convert their point cloud data to web pages (which has several html, js, css) zipped into files of about 2-3 GB (because of the size of the point cloud data). It is not possible to download all files at one go to the client browser. This is handled by potree web page itself. Based on user browsing, the html page fetches portion of the data and sends frequently. However, we don't have to worry about it as it is completely managed by Potree dev team ( Thanks to Institute of Computer Graphics and Algorithms, TU Wien)

So, we cannot do much with the html site we receive from our sub contractors. Our work is to host and provide secure access to stake holders.

APPLICATIONS: Initially I had developed two applications and also had a converted html page from Potree converter.

1. React JS web app : For working as a front end (Let's call App 1)
2. Dot net core 3.1 backend: For handling API requests. (Let's call App 2)

This project is hosted in IIS. So, I created a new site (running on a different port behind a firewall and not exposed to external parties). Let's call this as Target Site

Reverse proxy setup through IIS

1. We set up a reverse proxy in IIS (through ARR) for all incoming requests.
2. IIS will filter the incoming URL which has a particular string in the URL. (For example, /5506f977-7463-4f85-86ff-7ca63bac34fa/ , lets say url_guid).
3. URL Rewrite will change this and direct to the target site (running on different port behind firewall)

**Target Files setup **

1. Each time we receive new target pages (converted zip files) from sub contractors, we take the index.html file, rename it with GUID (target_file_GUID), add a tag to the header to include the url_guid and place it in a common directory.

2. We add the target_file_GUID to a column our Mysql database table which also has a column to store the actual name of the file.

Solution

1. From App 1, we send requests to App 2 (with JWT authentication in headers and the required HTML file(or the point cloud model)).
2. After validating, we fetch the guid name of the corresponding html file from the MYSQL
3. This particular file is then fetched from the common directory and sent to the browser.
4. At this point, the browser URL still doesn't change and contains the same URL used to reach the API controller.
5. When the Html file is loaded, it also tries to load the required JS, CSS files mentioned in the html. The trick happens here. Since we have specified tag, new url request is sent to the server which is intercepted by the IIS and rewritten to internal server. (At this point, the URL in the client browser still doesn't change because of the server Rewrite).
6. Client broser receives the JS, CSS files (but still the URL in the client browser and also the request headers doesn't show actual URL).

Conclusion I apologize for writing a long response and no much code. The whole setup and idea took more time to conceive (still there might be better way to handle it. I don't know).

The key achievements here are

1. authorize users before directing them to different URL.
2. URL Rewrite doesn't show the original url to the client browser
3. Original target site is still protected behind the firewall
4. the original file name of the html is replaced with GUID (which is hard to guess for the user) and this html guid name is changed repeatedly through a windows service console application every week. (Let's say we have 1000 files in total. The names change every week to keep it secure and confident).
5. Users cannot direclty access the html file (even if he knows the name of the file. Because this is served only through the App 2 after authentication)

More or less, we feel that at this point this is secure enough to proceed further. If someone else is facing similar issue and has achieved different solution, please do share.