What are cookies, anyway? Are they tasty?

A cookie is a small bit of information about you that the web server sends to your client. Your client then offers that information to the web server every time you visit a page on it thereafter.

Cookies are frequently used by web sites as part of their login process; when you enter your username and password, the server creates a cookie that contains a unique identifier, which your browser then stores and sends to the site whenever you visit, notifying it that you really are who you say you are.

This all sounds great. So what's the problem?

Certain less scrupulous sites may use cookies to track what kinds of advertisements you have seen or what sites you have visited to build up a list of advertising preferences. Because of this, many users may have browser options or third-party programs that restrict or eliminate the cookies that sites may store on their machines. This, unfortunately, interferes with that user's ability to log into LiveJournal, since a user's browser must accept a cookie to allow them to log in.

Further, some network settings on the part of the user or their internet service provider may have the same effect. Particularly, some internet service providers use proxies to serve requests; a proxy is a machine that sits between you and the site you are trying to contact, intercepts your request, and contacts the site on your behalf. Proxies are frequently used to supplement browser caches to improve speed of access for individual web sites. Unfortunately, some of them interfere with appropriate transmission of cookies, as well, causing users to be unable to log in or update their LiveJournal site preferences.

And, lastly, some users may have their clocks set in a vastly wrong way. Cookies contain expiration dates; if the client thinks that the cookie that the server is trying to set ought to have expired last week, it will throw it away without comment.

So what can be done?

Users may clear the cookies from their browser, to ensure that an old version of a cookie is not accidentally being used instead of a new one. Users may check their browser settings to ensure that LiveJournal is named as a "trusted" site, indicating that it may set cookies on the machine. They also may check other security programs to ensure that none of them are deleting cookies from LiveJournal. They may need to check their local network for devices that might interfere with cookies; some routers have been known to do this. And, lastly, they may contact their internet service provider to ensure that cookies are being properly set.

There is a FAQ which addresses precisely these issues, and this FAQ should be referenced whenever a cookie problem is suspected.

How can I tell if something is a cookie problem?

Here are some common signs of cookie problems:

• The user logs in successfully, but then is logged out whenever they visit a new page on LiveJournal.
• The user changes their page layout or language, but the setting never seems to stick between pages.
• The user is unable to use some feature they should be able to use while logged in, or unable to see protected entries they believe they should have access to.
• The user receives a message that says "invalid cookies". This is specifically a sign that they've recently switched to a paid account, and a separate FAQ is devoted to this issue.

It is also important to note that any of the above problems may also occur due to caching; for that reason, the FAQs that are used in these cases contain links to the cache-clearing FAQ. It should not be necessary to link to it yourself in most cases, although if the user is particularly confused and has already seen the cookie-related FAQs, you may need to make such a reference.

What does "Bind cookie to IP address" mean, then?

In theory, you will be sitting at a particular computer which has a unique IP address on the Internet. When your browser sends a request to LiveJournal, your IP address is one of the pieces of data that the server picks up. If someone else snoops on your session and tries to use your login cookie from their own computer then it will be coming from a different IP address. So you can tell LiveJournal that your login cookie isn't valid if it comes from any other address than yours, and this will protect you from people trying to steal your cookies.

Note that this doesn't stop you from logging in from another computer with your username and password. LiveJournal will generate a different cookie for that login, and you can thus bind it to a different IP address.

So what can go wrong?

If you are on dialup, or a connection which often changes its IP address, then binding your cookie to your IP address will cause you to get logged out every time the address changes (which, for a dialup connection, usually means every time you connect to the Internet).

More importantly, some ISPs use clusters of web proxies. When you send a request to LiveJournal, they intercept it and send the request on your behalf. Sometimes each request will come from a different machine within the cluster. If you have bound your cookie to "your" IP address, you will actually have bound it to the address of one particular proxy machine in the cluster. If a different proxy picks up your next request then you'll appear to be logged out again. This can cause you to appear to be randomly logged in and out, depending on which proxy your request hits on the way to LiveJournal.

The solution to this is of course to try disabling the "Bind cookie to IP address". This is one of the steps listed in the FAQ, so you don't need to state it explicitly to the user unless they have regreened the request.

What is a login, anyway?

Login is the term used to describe the process of using your username and password to prove your identity to a service, particularly to begin a series of communications with that service that will not require you to enter your username and password with every transaction.

This all sounds great. So what's the problem?

There are several kinds of login problems, some of which fall into the Web Interface category and some of which are really General/Unknown material:

The most common login problem is that the user is simply entering the wrong password. This may be occurring because the user has mistyped it, or does not really know it, or accidentally left the caps-lock key on. This is a gunk problem, and will generally be resolved in that category.

Login problems may also be caused by incomplete support for JavaScript in the user's browser. LiveJournal uses JavaScript to protect the password so that it cannot be intercepted between the user's computer and LiveJournal's server, but this means that a browser that does not support JavaScript completely will have trouble logging in.

If the user is unable to properly accept cookies, a login may appear to succeed, but then the user may be immediately logged out when they visit any other page. More information on this problem is available in the cookies problem-solving guide.

Lastly, login problems may occur if the user's account has been deleted and purged. In this case, however, the user will be notified of this when they attempt to log in; receiving a request from such a user is a rare event. This type of request should also be answered in Gunk, as it does not involve an error in LiveJournal or in the user's browser.

So, to recap: Questions about "bad password" errors and purged accounts should be sent to gunk if they are seen in Web first, so that at least one attempt may be made there to correct for user error. Other error messages, or unresponsiveness on the part of the brower, are Web problems and should remain in Web.

So what can be done?

A user may request to be e-mailed a link which will allow them to reset their password as described in the lost username/password FAQ.

If the issues are JavaScript-based, the user may enable JavaScript, add livejournal.com and theirusername.livejournal.com to any in-browser security or trusted site lists, and alter settings in their browsers which selectively disable JavaScript.

There is a FAQ that addresses all of these possibilities, and it should be referenced on any request that seems to be a login problem.

How can I tell if something is a login problem?

Generally diagnosis of login problems is relatively straightforward, since the user will be sent an error message explaining that they have failed to log in. In most cases the user will report this fact in the request.

What is a cache, anyway? Can I spend it?

A cache is a copy of some or all of the files from an internet site that your browser downloads when you visit that site. If you return there within a certain period of time, the browser displays the copies instead of going to the site again to retrieve the files, which speeds up your browsing and saves bandwidth for both you and the host in question.

Generally, a server will tell the browser how long a particular file should stay in the browser's cache for. Some files, such as the main search form for Google, are unlikely to change over the course of the day. Others, such as the evil overlord list, are unlikely to ever change. And still others, such as most pages on LiveJournal, are expected to change virtually every time you view them. In each case, the server will instruct the browser to only hold onto the file for the appropriate amount of time, so that the user never (or rarely) sees an out-of-date version of the file. Further, when the browser does ask for a new copy, it can ask only for information about the file (such as the time it was last updated) rather than the file itself, and compare that time to the last time it retrieved it, to avoid having to download the file again if it hasn't changed.

This all sounds great. So what's the problem?

The problem is that certain "browsers" tend to ignore the information that the server sends about how long a page should stay in cache for, and cache it for as long as they feel like caching it. Further, most browsers contain user-settable options that can override the server's settings for how long something should stay in cache. In either case, a user can be left seeing an old version of the page instead of the one that's currently on the server.

So what can be done?

There are some helpful howto tutorials which explain how to clear out the cache files in many browsers. Clearing these files will allow the user to see the most recent version of the page, and hopefully get around whatever problem they're currently experiencing. There is also a FAQ which addresses specifically this issue. The FAQ should be referenced in any cache-related answer; one should only link directly to the tutorials in cases where the user has somehow missed them in the FAQ, or other similarly unlikely circumstances.

How can I tell if something is a cache problem?

Here are some common signs of cache problems:

• The user reports that their friends page or journal isn't taking updates when they know updates have occurred, particularly if you can see updates that they don't seem to be able to.
• The user reports that the "Update Journal" link on the LiveJournal home page takes them straight to the results page (the one containing links to memorify or view the updated entry).
• The user sees information that should only be visible while logged in even after logging out, or cannot see information that should be visible after logging in.
• The user receives an error about the page being too old when attempting to log in.
• The user has received e-mail notifications of comments on a journal entry, but can't see them through the web interface.
• The user reports that something is behaving in a way which is not consistent with recent patches. For instance, the user may not be able to see newly-added elements on the comment interface.

Please be aware that this isn't an exhaustive list. Caching can cause many different kinds of errors, and diagnosing some of them may require some detective work. In fact, if you encounter some kind of strange problem, one of the first questions you should ask yourself is: how could caching cause this? You won't always find a solution that way, but cache problems will be a consistent nemesis for you as you continue your work in Web, and it's best to begin learning to hate them early.