Why private_html?

[conficio]

Hi there,
it just cost me a few hours to find out, that DA customizes apache mod_SSL server to find its files in private_html.

Why this weird set-up? It does not make sense, as many applications need only a few pages SSL save. And if you run a package such as phpShop, you don't want to split or duplicate the source tree, because it becomes a nightmare in maintenance.

It is also misleading, as there is nothing private about an SSL encrypted connection. The pages are still public.

I just solved the issue by making a symbolic link from pricate_html to public_html.

I'd like to request that this is changed or that the user interface tells me where I'm supposed to upload my html pages. The current comments somewhere deep in the documentation is not a satisfactory solution.

Kind regards

K<o>

[jmstacey]

http://www.directadmin.com/forum/showthread.php?s=&threadid=6590&highlight=privatehtml
http://www.directadmin.com/forum/showthread.php?s=&threadid=6681&highlight=privatehtml
http://www.directadmin.com/forum/showthread.php?s=&threadid=4832&highlight=privatehtml
http://www.directadmin.com/forum/showthread.php?s=&threadid=1630&highlight=privatehtml

One or more of these, possibly not listed, contains a deep discussion regarding this and was determined that it would remain as it is now since it can easily be changed in the templates.

[conficio]

Hi Jon,
thanks for the reply. I searched with the keyword ssl, and nothing came up (in the first two pages), should have looked for private_html :(

However, I find it rather remarkable to defend a practices that obviously gets so much rejection from the users.

All offered solutions are no real solutions, as they require VPS access and can't be changed without that interference on an account by account basis (assuming this is necessary as you insist on separate directories is the right practice).

I can't see the benefits of separate directories at all. If someone gains access to the ftp account he can change them both. If I want to prevent people from accessing secure pages w/o ssl, I'd do a rewrite (available to end users) or set my permissions accordingly (not available to end users at this point).

How about improving the user interface by providing vital information, such as where doc root is for public and private pages? That should at least save most people from having to research why their secure pages are not accessible.

I hope I contributed in a constructive way to the improvement of a good control panel.

Kind regards

K<o>

[nobaloney]

It's going to stay the way it is.

You can change it for your server by creating a post-creation script (see the links earlier in the thread) to change it.

There are many advantages to keeping secure pages in a separate directory, not the least of which is your vistors won't (even accidentallly) get a page insecurely which they should get securely.

Another is that you won't accidentally leave off an "s" in your code, and link to a page insecurely that should be linked to securely.

Plesk does it this way as well; I'm not sure about other control panels.

Jeff

[greentea]

I very strongly agree with conficio. In fact, what led me to search this forum was that our html pages and cgi scripts which redirect our users to https from http have now run into unforeseen problems.

Previously, before we used DA, we had no issues. Our previous web host configuration allows our users to access http://www.domain.com/pages.html and https://www.domain.com/pages.html with no problems.

Now, using DA, all our https links serve up pages full of missing graphics, errors, etc. We spents hours trying to troubleshoot, looking in all the wrong places until now I realised it's DA's problem.

Why private_html vs public_html? Whatever the reasons, a good control panel or any other software should give its users more options. E.g. whether we want to have both folders and how we want to use them. We have thousands of html pages. It would be stupid to duplicate them in both folders and chaotic to update them.

I was wondering whether we would have been better off with Plesk, when jlasman said, "Plesk does it this way as well." Well, Plesk is down for me too. But just because Plesk does it this way is no excuse why DA can't be different and do it better.

I know "It's going to stay the way it is." Meanwhile, we'll look for better control panels that are more user-friendly and treat its users better.

[jmstacey]

It is not that hard to reconfigure things (especially this) to the way you want them ;)

[nobaloney]

The easiest way to resolve the issue and still have the security is to have complete paths to all images, connections, etc., in all your secure pages.

But of course if you don't want the security you can simply do the link.

And you can even create a post-create script to delete private_html and create the link for you.

So what's the problem?

Do you need someone to write the script? If you can't do it yourself and would like someone to do it for you, just ask, and either someone else will, or I will and put it on my download pages.

Jeff

[thesti]

I agree with the thread starters. One of the reasons I am trying to dump Plesk is that annoying issue.

In my opinion there is no valid reason for and I have read the reasons, it just does not make business sense and I doubt people prefer it.

There are hack solutions such as symlinks but I think any CP should have a configurable option at least to either use one or two directories.

I am not trying to flame, I think DA is a great product, better than Plesk but I wish they didn't do the SSL and non SSL dirs

[rldev]

Thesti.
There is no reason for directadmin to do anything. There are several simple solutions on this forum to deal with this. I have my DA setup so that it does not create the private folder.

[thesti]

Originally posted by rldev
Thesti.
There is no reason for directadmin to do anything. There are several simple solutions on this forum to deal with this. I have my DA setup so that it does not create the private folder.

It would be nice to have something out of the box that works that way.

Don't get me wrong, the solutions mentioned no doubt work but I would prefer to not hack around and play with symlinks like I have to do with Plesk. It can be a pain after an OS reload or other things that might happen :).

I still don't see the harm in hearing me and conficio out on this one --potential customers :)

If it is easy to hack fix why not just make it a standard option?

[jmstacey]

If DA made it one directory, think of all the people who would want it the other way whith two seperate directories ;)

It's a moo point (you heard me :p )

[Chrysalis]

Well a good rule of thumb is if you cant please everyone dont go for just pleasing 50%, add the config option and make everyone happy.

[rldev]

Thesti,
I don't think you understand what I am saying. You can make one simple change once. No symlinks and takes about 5 minutes to do. Here it is:

This is easy enough to do permanently yourself. I did it yesterday.

Sorry I forgot that you did not have ssh access. You will need to ask your host.

Step 1 from SSH:

cd /usr/local/directadmin/data/templates
cp virtual_host_secure.conf custom
cd custom
pico virtual_host_secure.conf
Change the private_html to public_html save and exit

Step 2 from SSH:
code:echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue

(This removes any existing private_html folders)

Step 3 from SSH:

cd /usr/local/directadmin/scripts/custom/

pico domain_create_post.sh

paste the following code in:

####################################
#!/bin/sh
#
# domain_create_post.sh - Runs AFTER a domain is created
#
# Remove private_html folder from user/domain directory.
#
rm -R -f /home/${username}/domains/${domain}/private_html
#####################################

save and exit.

chmod 700 domain_create_post.sh

Done.

test an account.

I guess there are other ways to do this as well, but this works well and DA will not overwrite this. Maybe this could be made into a tutorial since many people want to do this. John said he will coonsider making this a user level option. I guess it is easy enough for DA to do, but I don't see it as necessary.

[nobaloney]

It probably should be a user-level option.

The problem with your fix is that it's server wide.

Would an admin want to do it on request of only one client? If so, then what would other clients think of the change for any new sites?

Again, it should probably be a user-level option.

Jeff

[thesti]

Originally posted by jlasman
It probably should be a user-level option.

The problem with your fix is that it's server wide.

Would an admin want to do it on request of only one client? If so, then what would other clients think of the change for any new sites?

Again, it should probably be a user-level option.

Jeff

Sounds fine to me as long as there's an option :)

[rldev]

DA once said they would make this a user level option and that it would be fairly easy. Frankly I don't see a big deal either way. It's easy enough to give a client a private folder if they need it or vice versa. Since I get more questions about why is their another folder and why do I have to run my whole store in SSL, I leave the private directory out. Nobody has ever asked me for one in 7 years.

[urgido]

good post :)

[nobaloney]

But you're ignoring the fact that if everything is in public_html any user can use http, and send his/her credit card info in the clear without meaning to do so. Especially if the coder forgets to use https in the link. Do coders do that. Yes. Often. Because most of us have been taught to use simple links rather than fully qualified links.

I predict that, at least in the United States, which is taking more action on protection of credit card and identity information than ever before, within the next year it will be impossible to get a secure site certified to accept credit cards if it's possible to access the site insecurely by simply using http instead of https.

Even if I'm wrong, or if you're not in the U.S., do you really want to make it so easy to let your users create a site that allows insecure transmission of credit card numbers and personal information?

Jeff