Jump to content
Larry Ullman's Book Forums

Recommended Posts

Hi everone,

 

I am rapidly approaching the daunting prospect of going live. I have registered with a reputable service provider. Being a newbie, I am desperately trying to get my mind around cPanel and WHM. My initial impression is that getting my content installed on the VPS is quite a task.

 

My question is, should I be doing it, or should I be asking the ISP's support staff to do it for me? 

Link to comment
Share on other sites

Derekd,

Hi. I've put sites live in as much as I've put them into my test area on my own website so that clients can test them.

 

The things I've had to look out for when doing this was error reporting and file paths. I have error reporting on 'localhost' set so that it shows me everything, not what you want in a live environment. Also, depending on how you've set up your config file etc. check to see where your file paths are pointing, or you may find that you DB connection doesn't work, for example. Finally if you're transferring DBs and tables MySQL has a good export / import capability rather than typing them back up again. I like cPanel, I think it's OK. Don't know what WHM is. Good luck, and if it doesn't work first time, don't panic, just work through it one step at a time.

 

This is my first atempt at a forum 'answer' so if anyone else has any further points please chip in.

 

Cheers

Paul

  • Upvote 2
Link to comment
Share on other sites

Hi Paul,

Thank you for your input. I have amazed myself and got my data and scripts across. My next dilemma and uncertainty is whether I've got my PHP scripts in the correct place. According to the documentation, my path structure looks like the following: 

home/luxacom/ - Is described as "home directory - all files stored here are not visble on the internet.

 

home/luxacom/www/ - Public HTML directory, contains the files for your site. File and sub directories will be viewable by anyone on the internet.

 

This has confused me in that it seems all my PHP scripts should go in home/luxacom/www/php_code, and my includes folder should be home/luxacom/www/php_code(not real name)/includes. But if it is viewable by everyone on the internet!, would that mean the pages or the directories and it's content. The other option would be to put the includes directory in home/luxacom/includes/, which is the opposite to how I had it on my localhost, not sure now....???

 

 I have used Larry's config.inc code and the system checks whether the code is running on a loclhost or live host. I have changed my BASE_URL (home/luxacom/www/php_code/)and BASE_URI(home/luxacom/www/php_code/includes) constants to reflect the above. I think the next step is to activate the DNS. Will carry on afresh tommorrow.

 

Thanks again for the help Paul, it is great that you doing this too, me thinks I'll be bending your ear a lot, if you don't mind.

 

Kind Reagrds

 

Derek

Link to comment
Share on other sites

Derek,

My host tells me to put everything in the public_html directory.

 

So in this directory goes the various php pages, such as index.php, contact.php etc.

 

Also within this directory I have my includes folder and my images folder. My includes folder contains the header, footer, config file, CSS files etc.

 

I have placed my connect scripts one step above the public_html directory (where your host says that they are not viewable by anyone). I asked my host what the direct path to this location was, I believe that's a more secure way of doing it than a relative link. Your host may replace 'public_html' with another designation but the structure is otherwise the same.

 

I beleive that this is the best way to do it from a security point of view but if anyone out there has a better way then please holler.

 

Cheers

Paul

Link to comment
Share on other sites

I think Paul made some good points.

With that said, just a point of clarification:

Some web hosting companies use "www" as the web root, and others used "public_html". It doesn't matter which one your web hosting company uses though, as they're both denoted as the web root.

 

Also, Derekd, I would recommend setting your base URL to www.some-domain-name.com, and setting your base URI to "/home/luxacom/". This will allow you to easily reference files accessible over the Internet through your base URL, and reference files outside the web root easily by using the base URI.

If I recall correctly, this is what Larry does in his e-commerce book.

 

Also, I wouldn't worry too much about your PHP files being accessible over the Internet. So long as no errors are reported and nothing is echoed/no HTML is output, if someone tries to directly access a PHP script, they will get a blank page and nothing else.

With that said, you need to always make sure that you properly validate all input accepted from users, as they can potentially hack your site if you don't.

Link to comment
Share on other sites

Thanks for that HartleySan, that makes sense now, I will implement that asap. I have been pretty diligent in type casting $_GET ID's and validating them against the database, with some referential integrity checks across the database and exiting back to the index page if things do not tie up. I have also stored my session data in a database to tighten things up. My site will not be doing any e-commerce type transactions, but I still feel protecting customer names, addresses and contact details is stil crucially important.

 

I got Larry's e-commerce book more for the security aspect than the payment gateways. I have been toying with the idea of purchasing a digital certificate and using SSL around the registration and login scripts, but am not sure if this is necessary. I am however concerned about customers not engaging with the site because of this?    

Link to comment
Share on other sites

Derekd, that all sounds good. I think you are taking the right approach, and I agree that even if you're *just* storing users' personal data, you need to be very careful with it.

 

As for the SSL certificate, I think Larry would be better to comment on that than me, but personally, I think it's only necessary for when you're handling payment info.

Link to comment
Share on other sites

Don't mind with the SSL. While it's very noble of you to want to protect your users, the security level should reflect what you are trying to protect. Security is only a reflection of handling risk, and should be implemented accordingly. This does not mean security should be taken lightly, however, you seem to have a healthy perspective on the whole deal.

 

If you are interested in the topic, some information from Wikipedia might be interesting:

- http://en.wikipedia.org/wiki/Information_security

- http://en.wikipedia.org/wiki/Risk_assessment

 

My two cents. If they're even worth that.

Link to comment
Share on other sites

Hi everyone,

I'm going to add another 2 cents worth in that I agree with Antonio, I've never used SSL on login scripts etc, I was only going to use it on actual e-commerce financial transaction pages.

 

Saying that, a question. If, like I will be shortly, you purchase an SSL certificate for an e-commerce site my understanding is that you have it for the whole site. So, in that case, are there any disadvangaes to using it on more pages, such as logins, than you normally would? I'm basically saying, don't buy one unneccessarily, but if you have one anyway.

 

Here's an article about them that I found useful:

 

http://webnet77.com/SSL-certificates.html

 

Cheers

Paul

Link to comment
Share on other sites

Thank you fo all the input, helps me to connect a few more dots. The main concern I have about SSL is the overhead it incurs, and you might end up with a very slow responding site. The costs associated with quality certificates are also substantial. From a purely marketing perspective I am concerned about the messages that the browser gives to the user when accessing an HTTP:// site versus a HTTPS:// site.

 

Just as an aside how long on average does it take for new private nameservers to propagate??? Mine has been going for nearly 12 hours and still no luck with getting into my site.

 

Cheers

 

Derek 

Link to comment
Share on other sites

If you're hoping to make money from your site, then you need to plan on spending money, including on an SSL certificate. Marketing aside, this is more important as a security issue. 

 

Nameservers can easily take a day or two to propagate. It make take an hour in one location, two days in another.

Link to comment
Share on other sites

Hi all,

 

Abigail. How does shared SSL work? My understanding of SSL is that it was in the exact name of the website to give people the security that they were dealing with the people they thought they were dealing with? My hosting company supplies SSL from £10.

 

Also, as per my earlier question does SSL slow down a website or have any detrimental effects?

 

Cheers

Paul

Link to comment
Share on other sites

The way they do it is they bring up my page "inside their website". I'm sure there is a more correct way to say it.

 

So here is url for a secure page:

https://secure23.webhostinghub.com/~advice10/donate-treatment-now.php

 

My home page is: http://adviceofthequeen.com

 

I have to tell my code to go to

https://secure23.webhostinghub.com/~advice10/

or to

adviceofthequeen.com

 

User will probably get certifcate warning.

 

Incidentally, webhostinghub advices not to switch between secure and not secure while using their shared certificate but I do it anyway. It works very good but it takes some careful programming and I think that's why they don't like people to do it.

 

If you want, go to my site and see how it works from user perspective.

 

Also, I don't let SEs such as Google "see" my secure pages. These urls would be very bad for SEO, which is one reason I don't want entire site secure.. But https://adviceofthequeen.com would be fine.

 

Webhostinghub gives this shared SSL free and if yours is only $10 it probably is shared and not your own SSL.

 

Probably any SSL will slow down the site. That is one reason I only use it for

about 6-10 pages that access the database. I have about 150 other pages and I surely don't want those slowed down.

Link to comment
Share on other sites

Thanks again for the input from everybody. You right Larry, I invested in a good service provider (which I got from this forum - thanks), and to compromise the integrity and responsibility to existing and future customers would not be wise.

Link to comment
Share on other sites

Hi Paul,

 

Did you initially experience any database connection issues, even the support team at the ISP appear to be stumped. We have tried numerous things but still can't seem to make a database connection???

 

Cheers

 

Derek 

Link to comment
Share on other sites

Derek,

The problem I had was that my paths were incorrect, have a look at the paths in your config file.

 

Also look at the connect script itself, has the DB the same name in live etc. I also seem to remember getting myself a bit confused between my account password with my host and my DB password with my host.

 

Otherwise please post the error messages you get when you try to connect.

 

Cheers

Paul

Link to comment
Share on other sites

Hi Paul,

 

Sorted the database thing out at last but now I'm getting the dreaded headers already sent when logging out. Everything worked great on my local PC. The mysteries of change never seems to abide! Did you experience that too.?

 

Cheers

 

Derek

Link to comment
Share on other sites

Just been doing that thanks Paul. When I put it into my header just before starting db_sessions I get a 404 message - url not found after logging in. When I recall the url for the site, I find I'm logged in. Probably something to do with how the VPS is setup?

 

Cheers

 

Derek

Link to comment
Share on other sites

Hi HartleySan,

 

I managed to get over the initial problems thanks. Things tend to get a bit panicky when everything works perfectly on your local site, and  a few problems pop up when going live, late at night, oh boy.

 

Cheers

 

Derek

Link to comment
Share on other sites

 Share

×
×
  • Create New...