<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 14, 2013 at 10:46 AM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/14/2013 01:23 PM, Karl Newman wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yep, I'm aware of that, I was just hoping that was more backend functionality and that the user-facing portion can run on Apache, etc. Unless there's a simple way to set up proxying in Apache to redirect to this server...<br>
</blockquote>
<br></div>
Ideally, what will happen is all of the functionality previously available in MythWeb will become available directly from mythbackend. This means that new users will automatically get a working web-based interface that allows scheduling, managing recordings, and more, without having to become system administrators with experience in web server setup/configuration.<br>
<br>
However, since MythTV opens up /far/ more capabilities via the backend web interface than is appropriate to expose to the Internet at large (i.e. all of the Service API goodness) not to mention the fact that our server (including the server process and the web application code) isn't tested against the cruel environment that is today's Internet, I would like someone to come up with a nice proxy application that can be run on Apache or whatever. This will allow us to take advantage of Apache's existing (and well-tested) user authentication capabilities and all the work that's been done to ensure it is reasonably safe to expose Apache's ports to the Internet, as well as allow users to access MythTV's web interface using a "standard" port (i.e. 80 or 443), potentially where they already run other web applications. Then, users who want to expose a MythTV web interface to the Internet can do so with far fewer concerns than if they were to expose all of the backend's functionality to the Internet.<br>
<br>
Originally, I had envisioned the application as also providing a means of theming the HTML application by replacing the built-in application's CSS, but Stuart has mentioned he plans to provide a means to theme the built-in web application. Therefore, this shouldn't be necessary.<br>
<br>
So, all that needs done is for someone to make a little proxy application that a) only passes "appropriate" requests to the backend (possibly even allowing per-role (group of users) authorizations, ideally via some user-configurable mechanism that allows users to define how much functionality is available through the Internet-facing web application) and b) handles different content types effectively (i.e. doesn't block the ability to stream video/music/...). Obviously, this can start small with a "simple" proxy application and niceties (such as per-role authorization and user-configurability/<u></u>configuration pages) can be added later.<br>
<br>
Perhaps a developer with some experience in creating nice little web applications would like to jump in and do some work on it... :)<br>
<br>
Mike<br></blockquote><div><br></div><div>That would be something I could likely contribute to, but it's probably beyond my experience to start from scratch and architect the thing... :(<br></div></div></div></div>