This is written from the perspective of PHP, but of course Cookies themselves can be manipulated from whatever server-side language you use to code your web application.

So if your users only stay logged in for a few hours, maybe a a couple of days at the most, and you want them to stay logged in much longer, continue reading.

The main reason this method works is because it doesn’t rely on PHP to keep the session, and sessions on the server tend to get cleared out, which is probably the most common reason for users having to login again. Rather than rely on PHP garbage collection to work properly, you take control of a secondary session that you store yourself. When the primary login check fails (depends on your application), you check the secondary session against your own records, and if you find a match, you can auto-login the user, returning control to the PHP session itself. You can choose to be seamless about the whole process, or you can present your user with one of those unnecessary messages saying “Please wait while we find your account…”.

We will tell you how, but it comes with a warning: Sessions, and more specifically Session Cookies are a big source security of security leaks. Mismanaging your sessions and your user’s cookies could result in a security threat to your system and to your users’ data. You may want to take extra security precautions to secure your sessions, including but not limited to:

1. Tie your session ID to other information, such as the user’s IP address and/or browser ID string.
2. Give your users an option of how long to stay logged in. This way, if you also tie the session ID to the IP address, when they log back in after their IP changes, they can choose to only stay logged in, such as if they are at a public insecure location. (Their cookie could still be vulnerable while it is active though).
3. Setup your system to detect session manipulation. Of course this is more easily said than done. As an example, you could record IP’s that don’t correspond to a session. That way, if your sessions are tied to your IP, and a user’s session is accessed from a different IP multiple times, it may be possible to tell if that 2nd IP is an intruder. Not even close to “full proof”, but it’s one measure you can take. You can disable that IP, but if the user is using a series of proxies, that won’t help much. If may want to take the extreme measure of shutting your system down completely, or shutting that particular user out indefinitely until a later time.

Common Cause:

Garbage Collection. While that may not be the whole problem, that describes what’s usually going on. Basically, the Session has been lost (whether it expired, or was deleted, etc). The PHP session on the server side has been deleted, so the user’s session cookie (PHPSESSID) doesn’t correspond to a server-side session any more. In some cases, this may be the result of a user losing their cookies, which can happen for numerous reasons.

If your users Cookies get deleted, then you can’t really keep them logged in anyway, so there isn’t a good way to fix that without re-inventing cookies or something like that, so we won’t talk about that here.

However if the problem is server-side, then we have a possible solution for you.

Solution: Extra Cookies

Basically, you set another cookie of your own design, and record that in your database for a lookup when the main PHP session fails.

PHP opens it’s sessions automatically (unless it’s configured not to). This means it’s gives the user a cookie with a Session ID, and on the server that session is stored somewhere.

PHP has various garbage collection and cookie lifetime configurations.

Unfortunately, most people run their applications on shared servers, VPS servers, or dedicated servers that are configured to clean out cookies a lot. It may be a PHP configuration thing, maybe there is some custom software the server host has installed, maybe an old server that hasn’t been updating in a long time, or a combination of the above.

Also unfortunate is that it can be difficult to properly configure PHP and any other server-side software that may be controlling or deleting your sessions. You can mess around with php.ini or .htaccess and try to get the configuration right, but not only is that very difficult to test, it tends to be unreliable, because permissions to change settings on various servers is very dependent on their exact configuration and software versions.

Rather than rely on the server configuration, wouldn’t your sleep better knowing that your software will run correctly anyway, without having to wonder if it’s still working. Wouldn’t it be easier if you can rely on your own PHP code to do the job, knowing that it will work even if your site is moved to a different server? Sure, that’s why we just recommend running a 2nd mini-session.

So you have to generate an extra cookie, with a custom Session ID, and associate it with a user in your database. When the PHP garbage collection removes the main PHP session, or for whatever other reason the server-side session is lost, and the PHP session cookie becomes useless, hopefully your extra cookie is intact. If your application will first check the session to see if your user is logged in. When that fails, you need to insert code that checks your custom session and finds that user in your database.

So it basically goes like this:

1. Generate Session: Give user a new unique cookie with new unique session ID. Store the session ID and corresponding User ID on the server side.
2. Check that a user is logged in on every page load
3. When user login check fails, lookup the session you created in your database, and automatically login the user.

It might sound funny, because you are basically replicating the way the PHP session works and duplicating that process, but this really does help a lot and keeps users logged in for quite a while, as long as their cookies remain intact that is.

Example:

Here is an example of what the code might look like, but you’ll have to make some adjustments for security and what not:

1) Generate Session: Upon login, do this:

$newSessionId = md5($userId . time());
setcookie('mydomain-sess', $newSessionId);
mysql_query("INSERT INTO my_sessions SET sessionId = '".mysql_real_escape_string($newSessionId)."', userId = '".mysql_real_escape_string($userId)."'");


2) Login Check

Your system should do a login check on every page, which varies between systems

3) Lookup Session & Auto-Login

if (!$userIsLoggedIn) { //how you check this depends on your system
$sessionId = $_COOKIE['mydomain-sess'];
$qh = mysql_query("SELECT userId FROM my_sessions WHERE sessionId = '" . mysql_real_escape_string($sessionId) . "' ");
$row = mysql_fetch_assoc($qh);
$userId = $row['userId'];
  if ($userId) {
    //auto-login the user here
  }
}

IP Restriction:

If you want to tie the user’s IP into the session, you might just record the REMOTE_ADDR in the database, and check it in step 3:

1) Generate Session

$newSessionId = md5($userId . time());
setcookie('mydomain-sess', $newSessionId);
mysql_query("INSERT INTO my_sessions SET sessionId = '".mysql_real_escape_string($newSessionId)."', userId = '".mysql_real_escape_string($userId)."', userIp = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."'");


3) Lookup Session & Auto-Login

if (!$userIsLoggedIn) { //how you check this depends on your system
$sessionId = $_COOKIE['mydomain-sess'];
$qh = mysql_query("SELECT userId FROM my_sessions WHERE sessionId = '" . mysql_real_escape_string($sessionId) . "' AND userIp = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."'");
$row = mysql_fetch_assoc($qh);
$userId = $row['userId'];
  if ($userId) {
    //auto-login the user here
  }
}

But there are a variety of ways to integrate IP checking, so that’s just one example.

To give you a bit more detail:

1) Generate a custom Session ID, with a secure MD5 string stored in it. For example: Cookie “mydomain-sess” with value “d41d8cd98f00b204e9800998ecf8427e”. Give this cookie an expiration that corresponds to how long you want to keep the user logged in.

Save the MD5 string server-side somewhere, and associate that with a User ID. It’s most easily done via a database, but as it’s sever side, the storage method is up to you. In the database, you might have a table with 2 columns: “sessionId” and “userId”. Your secondary check does a lookup on the value of cookie “mydomain-sess”, and if it finds that user ID, then you would login the user automatically.

On subsequent page loads, that cookie will be sent to the server on every page load.

2) Every page load of your application should check if a user is logged in, usually just done checking if a Session user ID variable is set. This is the normal way to do it, and should already be happening, as a result of your server-side application.

3) When that check fails, that’s when you run your secondary check. You can look up the cookie in the DB and see if it matches a user. From there, you can just auto-login the user, however that must happen depending on server side software/PHP framework, and the PHP session will be re-created and re-used on subsequent page loads.

Also, you probably shouldn’t store a whole copy of your session with that session ID, not only would that be cumbersome, but storing multiple copies that can become different could result in problems along the way. I recommend just logging in the user automatically, thereby re-creating the PHP session.

When your auto-login occurs, you can throw up some fancy-pants unnecessary message like “Please wait while we access your user account…” with a fancy little rotating GIF or something while javascript waits 5 seconds to reload the page, or you can just load up the session immediately and allow your application to run normally, making it completely transparent to the user than anything was going on, it will just seem like they never logged out.

1. Create a Good Password: Choose a ridiculously long password, at least 20 random characters, including numbers and special symbols.
2. Protect Your Password
   1. Never let anyone have your GoDaddy password
   2. Don’t store your password on your computer – it can get stolen by hackers, viruses, or simply by unauthorized users, and it can get lost easily among all of your files or by a hard drive/system crash
   3. Keep it written down on paper, ONLY on paper, somewhere safe – even inside of a safe!
3. Change your password every 6 months. Old passwords are more likely to get stolen.
4. Keep your PIN number with your password. GoDaddy and some other registrars allow you to create a 4-digit PIN number for support. Keep it with your password, you’ll need it.
5. Do not login to GoDaddy from public locations, such as coffee shops and other free WiFi hotspots. Information transmitted over WiFi is easily captured, especially if there is no WiFi password, but it can even be stolen if there is a WiFi password. In fact, it’s best to avoid WiFi altogether, and to only login from a hard-wired connection. This tip goes for any secure information or passwords.
6. Save Your Nameservers: If you have lots of domains in your account, or even if you only have a few domains, take a snapshot of your Nameservers periodically. Knowing the correct nameservers in case they get changed can save you a lot of hassle of having to track them down after an incident. Resetting nameservers has been known to happen by using the feature in GoDaddy that allows you to modify many domains at once.

Many people are curious about how to perform a full AJAX file upload using jQuery. Some users have noted that HTML 5 supports AJAX file uploads, however most websites aren’t written in fully support HTML 5. Other users have also shown exactly how to do this using methods such as hidden iframes, and a Javascript XMLHttpRequest() object.

The fact of the matter is, this is another place where you rarely need to write any code from scratch. We highly recommend using a jQuery Plugin for AJAX File Uploads, and there are many jQuery Plugins just for that purpose.
We recommend the “jQuery Form Plugin”, at http://malsup.com/jquery/form/. It lets you submit any form via AJAX, so it much more useful than just for AJAX file uploads, and it supports a callback function for a progress bar. It’s very easy to use, and if you already have your form created, you can integrate this plugin very easily:

$(document).ready(function() {
  // bind 'myForm' and provide a simple callback function
  $('#myForm').ajaxForm(function() {
    alert("Thank you for your comment!");
  });
});

We found the ajaxSubmit() method even more useful, since we could trigger the form submission at will. The options available to this function match many of the options in the standard jQuery ajax() method, and overall this plugin made life very easy.

If you have other requirements, such as multiple file upload, try searching Google. There are so many jQuery AJAX File Upload plugins that it’s not even worth covering them all here.

But Microsoft has given one claim to Windows 8 Metro Apps that, until today, I found to be true.

Windows 8 Apps are supposed to be light on your system when not in use. When they are in the background they are supposed to use no resources, or almost no resources. However, I was watching a movie yesterday in the Windows 8 Video app, and although the movie was paused, and the app was not even in focus, it was in the background, I noticed in the Task Manager it was taking up over 100MB of memory. That was shocking to me, because I know that 100MB of wasted memory can be a drag on my battery life. It might not bother you for your desktop computer (unless you are concerned about green PC’s and low overall energy usage) but in this case, I found it to be an abomination, a true shame.

Overall I’ve had a pretty good experience with Windows 8 apps (aside from the lack of official apps, the lack of useful apps, and the lack of settings within apps), but perhaps I just have low expectations after waiting so many years for a version of Windows that can compete with the modern world.

Part of using Windows 8 on a laptop that is often running on battery is keeping a close eye on the Task Manager, and being sure to close unnecessary programs, and restart browsers when there is an apparent “memory suck.” Very unfortunate, especially since I’ve always been such a Windows lover.

After a few months of using Windows 8, I find that one of the main reasons Windows 8 Apps are useful is because of shortcomings in other software.

For example, we want to use Windows 8 apps to play streaming music like Pandora, or to look at Facebook. But those are pretty lame reasons to develop and use a whole new App platform. I mean, those are already available in a format called “the web” and accessible using something called a “web browser.” So why do we prefer the apps over the web versions? In these cases, the Apps trump the web-based version simply because of computer resources. Having a browser open just for Pandora can drain battery and hurt performance, and the same applies for many other programs and web services.

Personally, I use a separate browser for Pandora, because Flash can be draining to my computers resources, and to my browser’s performance, I like to keep it separate. It lets me browse the web faster using my primary browser, while listening to music in a separate browser. Sometimes I even use a 3rd browser. But all this is a true failure of software: A failure of web browsers to manage their resources effectively, a failure of web browsers to manage their extensions efficiently, and a HUGE failure of Adobe to manage Flash, which quite honestly uses a ridiculous amount of resources, has obvious memory leaks, and can slow a computer down and hinder it’s battery life to a point that Adobe should be ashamed of. But we can’t only blame Adobe for this, we should blame the web browsers that allow this kind of brutal garbage to be integrated into their software. The end-user has very little influence to get Adobe to fix Flash, but Mozilla, Apple, Microsoft and Google all have web browsers that are being hindered by Flash, and they have done little to address the problem. Most of their efforts center around allowing Flash to run in separate instances of the browser, which basically just allows Flash to crash, and to hog up resources.

Other than that, Windows 8 apps have very little usefulness, especially considering the lack of official apps for services like Facebook. I love that Microsoft has taken a new direction with Windows 8, but they have given very little purpose to it, and very little reason to use it.

Shame on you Adobe!

And shame on you Mozilla, Microsoft, Apple and Google for not pushing to get this fixed!

Writing Javascript and AJAX code from scratch can be extremely time consuming, and it’s important to keep inn mind that Javascript only accounts for 1/5th of your web application, maybe less, and wasting too much time on your Javascript should be avoided. In addition to Javascript, you’ve got CSS and HTML to write, as well as your server side language and DB language (ie. PHP and MySQL). That’s 5 language to manage, 5 languages to incorporate, and that’s without even considering mobile apps.

On top of that, you’ve got 4 major browsers to test your code in (IE, Firefox, Chrome, Safari), and it all becomes a bit of a blur when you’ve been working on a project for some time.

jQuery aims to improve web application quality, as well as make it easier to write Javascript by providing a powerful, cross-browser framework to work with.

Unfortunately, jQuery can still be very tricky, and in many ways it becomes a 6th language in your application.

That’s what it’s important to keep some things in mind:

1. Selectors: jQuery selectors (ie. the .. in “$(…)” ) are often the source of problems, and getting the correct selector can be key to fixing your problems. Often it’s the difference between specifying a list vs list item that is the cause of your jQuery pains
2. Find Examples: Unfortunately, the jQuery documentation is very – well – “documentation based.” In other words, it’s designed around describing the features of jQuery, without actually showing you examples, and the lack of examples within the jQuery documentation can cause massive headaches.
3. jQuery UI: Not really a part of the core jQuery, it’s critical to almost everything you’ll do in jQuery, so look it up, learn it, adapt to it.
4. Time: Writing Javascript takes time, even if you’re good at it. Devote the time and chances are that you’ll learn and achieve what you desire.

Hopefully those tips will help beginners, just don’t forget that putting in the time is necessary no matter what.

The jQuery .load() documentation shows 2 optional arguments to the .load() method.

The first optional argument is “data”, which is described as “A plain object or string that is sent to the server with the request.”

The second optional argument is “complete”, which is described as “A callback function that is executed when the request completes.”.

The examples on that page present some confusion, by showing this example:


$('#result').load('ajax/test.html', function() {
alert('Load was performed.');
});


The problem with that example is that the “complete” callback function is shown as the 2nd argument, not the 3rd.

Many users seem to have it working fine using the complete callback as the 2nd optional argument to .load(), however we had consistent problems with it, and so have some other users. The problem is that the function gets called before the .load() completes, essentially calling it before it is even sent, and then sending the result of the callback function as the “data” argument.

However, we found a quick fix: By placing “null” as the optional 2nd argument, the complete callback function then begins to work properly.


$('#result').load('ajax/test.html', null, function() {
alert('Load was performed.');
});


The specific problem we had was that we were trying to center the layer after it loaded. Trying to center it using the complete callback function didn’t work when used as the 2nd argument to .load(), it would center a blank layer, but using “null” as the 2nd argument, and moving the complete callback to the 3rd argument fixed the problem, allowing the layer to be properly centered.

The really strange thing is that many users get it working just fine using the first example. Depending on what people are doing with the complete callback function, it might make sense that it seems to work even though it’s calling the callback too early in some situations, and seems to not work properly in other situations.

We don’t know if this is a shortcoming of the jQuery documentation, a jQuery bug, or a misunderstanding on our part of the proper usage of .load(), but what we do know is that using “null” as the 2nd argument seems to fix the problem.

The errors resemble the following:

• “not well-formed” (maybe referring to a specific piece of returned HTML)
• “mismatched tag. expected </input>” (or “expected </option>”, “expected </td>”, “expected </br>” etc)

Chances are you are using jQuery’s load() or get() or ajax() functions and sending a response back to jQuery via PHP or another server-side langauge.

The problem is that jQuery doesn’t know what response type is coming back. If you return a plain html file (ie. filename.html) then the web server automatically adds Content-Type response headers. However if you are using PHP, the Content-Type is not automatically generated.

To fix the problem, add this to your PHP:

header(“Content-type: text/html”);

Or use whatever Content Type applies to your response.

And remember, we’re talking about the response header (response coming back from the server) – not the request header (request sent to the server).

A: Although there could be several reasons for this, one common problem is that you have set your DIV’s style attribute to specifically hide the layer using “visibility:hidden;” and “display:none;”. In many Javascript implementations, in order to change that value, both of these attributes must be set explicitly in the “style” attribute. For example:

• <div id=”layerID” style=”visibility:hidden;display:none;”>text</div>

Traditionally, you would use javascript to modify the style attribute in order to show the layer.

However jQuery is slightly different. If you explicitly set the style attribute to “visibility:hidden;display:none;” then jQuery will not be able to show the layer. The solution is to remove the visibility attribute from your style tag, so only the “display:none;” attribute is left. For example:

• <div id=”layerID” style=”display:none;”>text</div>

An alternative would be to use jQuery to hide the layer upon page load. For example, here is your DIV:

• <div id=”layerID”>text</div>

And here is your jQuery which hides the layer once the page is loaded:

• $(document).ready(function(){
  $(‘#layerID’).hide();
  }

You might be trying to show or hide a progress bar or waiting message while you are waiting for the AJAX response to come back, or you might just be trying to show and hide layers for other reasons. Either way, we hope this tips helps!

We also recommend checking out Free AJAX Loading GIF Generator.

Curious why Windows 8 desktop doesn’t show your files and folders?

Microsoft made some major changes with Windows 8, but it also made a lot of very small changes. By default, Windows  does not show any icons on your desktop. This can be very confusing, especially when you browse to the Desktop through the File Explorer and can see your icons just fine.

There are 2 different places for Desktop Icon settings in Windows 8

1. All Desktop Icons: Right Click on the Desktop and go to “View” > and then click “Show desktop icons”. This will show any file and folder icons and other special icons that are located on your desktop.
2. Special System Icons: Right Click on the Desktop and go to “Personalize” and then click “Change desktop icons”. This will allow you to enable or disable icons for special system folders such as My Computer, Recycle Bin, and User’s Documents. You also need to enable “Show desktop icons” per #1 above in order to see these icons on the Desktop.

Keep in mind that the Desktop will be much cleaner by leaving the above options set to default. Also keep in mind that in order to show system icons on the Desktop, you need to enable “Show desktop icons” per step 1 above.