Umm, CK9, a link's URL does not need to be the link's text. You can have a short descriptive text, and a long messey URL underneath to do the redirect.
But, now that I know more about what you're doing....
A lot of web apps have a number of pages all being displayed from 1 source file. Essentially, that page gets variables passed to it that identify which page to display. If none are passed, you can probably assume the login page should be displayed. Internally, you use something like a big switch statement to display each page. Perhaps the code to output each page is it's own function, or maybe it's own class.
Partial Ruby Example (I'm more familiar with Ruby than PHP):
# Rather than a switch, I'll use a hash (called a map or associative array in other languages)
pageList = { 'login' => DisplayLoginPage, 'main' => DisplayMainPage}
page = params['page']
pageList[page](params)
def DisplayLoginPage()
# Output Login Page HTML here
puts '<html>'
# ...
end
def DisplayMainPage()
# Output main page (after login) here
puts '<html>'
# ...
end
You'll notice the forum software does something similar. It always uses index.php, but you'll see different variables passed to it after the "?" telling it what page of the forums to display. Instead of the "page" variable used in the example, the forum seems to use an "act" (action?) variable.
Handling Form SubmissionsThere are two ways for the browser to fetch a page. There are "get" requests, and there are "post" requests. Following a link is always a get request, as is fetching referenced images, and other files (CSS, JavaScript). Form submissions are usually handled by post requests, although, they can also use get requests. Generally, if the submit button causes a permanent action on the server, such as submiting a post, which is then written to a database, you'd use post. If it's more of a read only request, such as a search button, you might use a get request. The method chosen affects how variables are passed to the server, and the maximum size of the data passed. It also has some security implications. The security implications are probably the best reason to separate out the get and post requests according to that guidline I've just stated.
Clearing PostThere is one annoying thing about post requests however. After you've fetched a page with post, if you hit F5, or select "Refresh", it will pop up a dialog box asking if you want to resubmit the form variables. This is rather annoying, and in the case of a login page, if you clicked yes, it would actually go through the login process again. To avoid this, any post requests can be changed to a get request by using a redirect. What you do, is set some form processing code to handle the post request, and after the action has been completed, redirect the client to a proper landing page. After the browser sees the redirect response, it will make a get request to the landing page, thereby clearing the post, and not prompting them if they try to refresh the page. Note that if the action may succeed or fail, the form processing code may choose to redirect the client to either a success or failure page (or an existing page with an extra variable set to display an error message).
Usability and SecurityIf someone copies and pastes a URL to someone else, containing all the messy get variables at the end, then someone else can see that page. This could be nice for dynamic pages, such as search results, where something interesting comes up that you want to share. Hence, a get request, by exposing the variables in the URL, allows you to send someone else that URL so they can also see the same page. This is not possible with post requests however, as the variables are sent in the body of HTTP request, which only get sent by filling out a form and clicking it's submit button. Hence, any secure "actions", should be done with post requests, to prevent the old "hey, look at this!" trick, where someone pasts a link to do a bad action, on the unsuspecting user's account.
Example: Suppose there is a banking application, that has a form to transfer money, and it is handled by a get request. Some unsuspecting user A has logged in to this banking application, and is checking on their finances. Some evil user B somehow knows or suspect user A is currently logged in to that banking application, so they send them a link about "the generic interesting news event that just happened", which is really a link to the form's action URL (that leads to the form processing function), and has variables set to transfer all the money from user A's account to user B. Unsuspecting user A thinks "generic news event" is interesting and decides to click the link (either not noticing the underlying URL, as it may be hidden, or perhaps because they don't understand all that computer mumbo jumbo even if they did see it). The broweser makes a request to the bank to "get" that URL, with all the variables attached, and also sends any cookies current set by that site with it, such as User A's login credentials. The bank then validates that User A's login credentials are valid (which they are, because user A just happens to be logged in currently), and proceeds with the requested action. Now user A is in the poorhouse.
Login PagesThe login page, is generally a form. It will probably take some option variables to display messages such as "Invalid Username or Password". These variables will default in such a way that nothing is displayed. When the user submits the login form, the server handles a post request. If the login is good, it setups up session variables in some local database or similar (as HTTP is stateless, so they have to be remembered somehow), and sends back a redirect request, which also sets the login session cookie. The landing page will be the main one after login, which might be a URL such as "
www.yoursite.com/someFolder/index.php?page=main". If the login is bad, it redirects back to the login page using a URL such as "
www.yoursite.com/someFolder/index.php?username=CK9&Message=1". I included a userName in the URL so the login page can auto fill it in as a default, so they don't need to retype it if their password is wrong. The message variable can then be used to select some predefined message, such as "Bad Username or Password".
I should mention there are also quite a few important security considerations when writing login session code, but perhaps I'll save that for another post.
