Internet Security: Why Log Out?
Posted by mcgelligot in Security on January 26, 2012
Be Secure...LOG OUT!
You know why it is important to log into your account on your various secure destinations. First, you can’t access your info unless you do! But more importantly no one else can access the info unless he or she can get your user name and password. So your account is safe right?
Wrong, there are devious ways of getting your user name and password. One easy way is through packet sniffing. I am convinced that packet sniffing is a routine operation around hotels, restaurants, etc. I have had my servers broken into TWICE while I was on vacation. Both times it was after I logged into an FTP account. Malware was installed both times and it was alot of work to get things straightened out, not to mention the fact that all that time spent trying to fix the problem put a damper on my vacations.
Well, there is no better learned lessons than those acquired in the school of hard knocks. I put my servers on SSH. That was just the start. I reviewed all php code and forms on the site. I created software to monitor changes to vulnerable pages and severely limited access to website code. Any suspicious onsite changes are logged and I am notified by email. That was two or three years ago, and I have been unassaulted since. However, without taking further precautions, I could still have been vulnerable to attack. In fact we are always vulnerable to attack, even with seemingly secure accounts especially if we go about getting into accounts while using publicly provided internet. Because through packet sniffing (someone watching the flow of traffic on a particular hub) doesn’t always need a password and a user name. They can simply piggy-back their way into your account by mimmicking your authentication process and headers. As long as your account is open a hacker could theoretically operate inside your account. The way to preclude or at least foreshorten this possibility is to LOG OUT!
I presume you are already savy enough to know that you must log out of accounts and close the browser on public computers so the next user can’t access your account.
For the user taking advantage of a “hotspot”, the best policy, especially in a public place is to make sure to have a secure connection (look for the green bar on the Url at the top of the page), know what you want to do when you log into your account, get your business done, and don’t forget to log out.
Google AdSense Does NOT Appear on Kindle Fire
Posted by mcgelligot in Miscellaneous, Statistics on January 25, 2012
I just got a Kindle Fire. I decided that I should take a look at my own websites just to see how they looked on the 7 inch screen. The sites appeared okay, but much to my wondering eyes did NOT appear… well there was no miniature sleigh or eight tiny reindeer, but neither were there any Adsense ads.
What to do? What to do? I could write an application that would change it to a different ad, maybe Chitika, when a Kindle browser shows up. In fact, I probably will do that for one or two of my sites, but so far Kindle web traffic is not high enough to worry about it too much. I have not seen too much traffic thus far from the fire, but it is sure to grow the way the item has been selling. On the other hand it seems to be a device more in tune with selling books, mags, music, and movies. The internet side will probably grow slowly. No doubt the situation can change as well.
In any case, I find Amazon’s approach interesting and also disturbing. Blocking ads on my websites is like stealing content from me. It is amazing how the big boys never play by the rules. The only way I can continue to create content is to get paid for doing so. Meanwhile I am sure the boys at Amazon think they are only tweaking Google.
It’s just one more development to react to.
X and Y Axis Page Layout
Posted by mcgelligot in Content Creation, css on January 25, 2012
The current manifestation of this blog has a column that runs up the right side and overlays the horizontal nav bar at the top. I admittedly like this look. I call it the X and Y axis page layout. This is because, for me, it resembles a cartesian plane with the column representing “y” and the nav bar representing “x”. I think I like it because it makes elegant use of the space available and over the years I have gotten tired of the same-ol’-same-ol’ with page layouts.
In any case, I decided to do a redesign of Learn Chess Rules. I decided to employ this design concept in the simplest manner possible, using something close to primary colors. I wanted to see the format in its essense. I also employed a fixed div at the bottom of the page. I like the effect, but the wife liked the ambiance of the site before I changed it. At this time many of the support pages are still in the old format, the FAQs for example, so you can see the difference.
I originally wrote the Chess Rules site in 1998. My memory has me starting at ten in the evening and working to four in the AM. If so, I was working fast. The redesign and rewrite took me two days.
The internet moves faster than a speeding bullet, and even faster than Superman. When I wrote the site it was all tables. Even though in the rewrite I employed a table here and there, where appropriate, the entire structure hangs on the <div> tag and the CSS behind it.
X and Y Axis at Learn Chess Rules
DCL SQL GRANT and REVOKE
Posted by mcgelligot in SQL on January 21, 2012
SQL is broken up into several sub-languages. One of these is DCL which stands for Data Control Language. What it is really about is designating who has permission to do what on a database. Ultimately, this is a security thing. If we could implicitly trust everyone, we would just grant all power to everyone. In the real world of the anonymous internet this would fall into the category of FAIL.
Thus, SQL gives us the ability to GRANT and REVOKE. Actually, on php myadmin in cpannel, you cannot do this with an SQL command, it is done through a UI when the user is created. Basically GRANT gives permission to do various things, and REVOKE takes those permissions away.
The system works logically in that a user has no permissions unless first granted them. Thus we have no REVOKEs without first, somewhere along the line, having a GRANT. The key to GRANTs is to keep them to a minimum. The less access users have to a database the less likely they are to screw things up. Of course, this must be balanced with the needs of the many, which Spock will tell you, out-weighs the needs of the few, we happy few, we band of brothers. Never thought you would see Spock and Henry V quoted in the same sentence did you? Suffice it to say there is a balance.
For most purposes, REVOKEs are used when an empolyee leaves a company or a user loses status (say a subscription lapses). The syntax for REVOKE follows:
REVOKE privilege
ON object
FROM user or PUBLIC or role
For a GRANT, just replace “REVOKE”.
SQL Nullification: IFNULL(), ISNULL(), NVL(), COALESCE()
Posted by mcgelligot in SQL on January 18, 2012
Okay, let’s get our act together. To find out if a cell is NULL why not just ask…ISNULL? Well, yes, this does work for mySQL. But it isn’t that simple. What if we wanted an easy way to replace the null value with something else? Good idea you say. So the powers that be at mySQL came up with IFNULL(). It looks like this:
SELECT IFNULL(column1, “alternative”) FROM table
So if the expression in column1 turns out to be NULL you can make it something else.
Where it gets a bit confusing is that some applications use ISNULL() the way mySQL uses IFNULL(). And some use a completely different syntax. NVL() is how it looks in Oracle.
But there is another way of doing this available in most applications. It is called COALESCE(). This looks alot like IFNULL (mySQL) but has the added feature that it can take multiple parameters and will in the end return the first one that it finds that is NOT NULL. So you can do something like this:
SELECT COALESCE(column1, column2, etc., “alternative”) FROM table
This will return the first not null param that it runs across. Leave the failsafe for the end.
All About SQL JOINs
Posted by mcgelligot in SQL on January 12, 2012
Normalization is a way to reduce the amount of time it takes for tables to do their processing. It involves reducing tables to the least number of necessary columns. However, this can create a problem when putting the data back together to present desired output. To solve this problem, JOINs were invented in SQL. In a JOIN two columns from two tables are compared to find out if rows should be meshed together, then the rows are combined. It effectively makes one table an extension of another.
For example, we have a list of customers and a list of transactions. We have a customer number for each customer and that customer number is listed in the transaction log. Since we already have all the info we need about our customers in the customer table, we do not need to also store it in the transaction log. All we need do is list the customer number. So when we need to send an invoice to a customer, we can perform a JOIN on the two tables. This will recall the transaction and with the reference to the customer table get the name, address, etc. Alternatively we could also use a JOIN to find all of the transactions by any specific customer.
For the NEWBIE there is a bewildering list of SQL JOINs. Yet they all have a purpose:
First there is the INNER JOIN. This combines the information from two tables based on a comparison of two columns. It outputs only rows that are found in both tables.
A LEFT JOIN will output all the rows in the left table (or first) table and any associated info from the right table. If there is no info from the right, it will leave those cells blank.
The RIGHT JOIN is similar to the left, only in this case, it is all the rows on the RIGHT that will be listed with unfilled cells left blank.
A FULL JOIN is like a RIGHT and LEFT JOIN together. All rows are listed with the appropriate rows meshed. Blanks will be left in rows with unmeshed fields.
To confuse matters perhaps slightly, there is also the UNION. This works alot like a JOIN only it combines two SELECT statements rather than tables. The result is a list of all the unique info from two selections from like table columns.
Hope that clears things up.
PHP mail() function and From Header
Posted by mcgelligot in Php Coding on January 5, 2012
Yes, I knew you wanted to read about another development on the PHP mail function front. So here it is: you can use the “from” header on some servers and not on others. Some mailservers will reject an email with a “from” header (with out of state plates) out of hand, on the possibility it is spam. Others will allow you to send a message with it.
Why do I need to include the “From” header in a mail message? As previously explained, I am developing a universal contact module that can be included on any website. Not all that complicated…you would think. But as my dear old granddad used to say between spits of tobacco, “It’s always sumpin’.”
I wanted to make it easy to respond to messages sent by the contact form, so I included the “From” and “reply to” headers. It worked fine on one server, and I thought, great, now I will just start installing this module on all my sites. The first one liked the “From” module, so did the second, but when I hit a different server, it did not like it.
As it turns out, you don’t really need the ”From” header in the email to allow a one click response form to show up on your email program. So, I have simply removed it. The “reply to” still works fine.
Useful Links:
