I'm making a bank....

[Kaiser Mors V]

I've got everything working!!!!!!!

[Neike Taika-Tessaro]

I've got everything working!!!!!!!

Awesome, you beat PHP into submission! ^___^ *applauds*

[Ari Rahikkala]

Now, if you want to integrate it with phpBB3, here's where the pain starts

[Kaiser Mors V]

Yeah.. well...I'll do that some other year... now I need to actually make the aplication, all I have now is all the database stuff done.. (well.. delete account isn't up yet..but meh...) So now that I've beat SQL into submission, now I truely get to beat PHP into submission... and HTML forms...

[Braden Indianensis]

Man, our virtual bank in Antica was a total bust. Other than the technical problems, it just didn't work...

[Chrimigules]

It didn't help that Aryez flooded it with money right as a value for the Pecunia was stabilizing out.

[Braden Indianensis]

OMG, that was dramatic: the entire Antican nation collectively ripped Aryez a new one, even those of us who were ambivalent toward the economy.

[Kaiser Mors V]

This is why there tends to be a set amount of currency in Shireroth. (technically backed with US money I have in a large container)

[Nick Foghorn Leghorn]

Yeah, the economy was just about to start really ticking, and then Aryez floods the market. I still haven't forgiven him for that...

what was it, 200p for every citizen?

[Braden Indianensis]

I think so. Aryez was hoping to dole out Mana from Heaven, but instead he got a plague of locusts.

[Kaiser Mors V]

So I have an account creation page.. next. login! (this means I got forms worked out...)

[Kaiser Mors V]

Which reminds me.. I suppose I should be looking into Sessions about now...

[Kaiser Mors V]

btw... I'm using a hidden field to tell myself when they have hit the submit button. but when I check it the first time.. obviously... they haven't... and because of my error checking.. I'm getting notices.. is their a built in way to check this?


I found a solution using isset($_POST).

[Neike Taika-Tessaro]

btw... I'm using a hidden field to tell myself when they have hit the submit button.

You can also give the submit button a name and check if that variable has been set. However, the cleaner, 'hack-proof' way is to check the fields you're expecting to have been submitted. Try this:

Code: Select all

function fields_set($array_of_field_names) {
  $fields_sent = true;
  foreach ($array_of_field_names as $field_name) {
    $fields_sent = $fields_sent && (isset($_REQUEST[$field_name]));
  }
  return $fields_sent;
}

if (fields_set(array("name","password","..."))) {
  // do something
}

Or, if you're rigorous and don't use 0 as a valid value of a form field, I recommend using empty(trim($_REQUEST[$field_name])) instead of isset($_REQUEST[$field_name])). (In the context of doing something sensible with all elements of an array, by the way, array_map() is quite interesting, too.)

I found a solution using isset($_POST).

Yeah, that works - and is probably sufficient for your purposes.

[Neike Taika-Tessaro]

Ack, missed this post somehow.

Which reminds me.. I suppose I should be looking into Sessions about now...

Okay, a bit of background information: the concept behind sessions is that server-side variables are tied to a single client-side variable (the session ID), usually a hexadecimal string that looks like a hash. It means that you have complete control over the contents of the server-side variables and your user can't tamper with them - unlike with POST, GET or COOKIE data. They can of course try and manipulate the session ID, but chances are they won't find an active session that way.

You can pretty much ignore how sessions work client-side. PHP does most of this automatically. But, for the sake of argument, let's say we're using cookies for sessions, just so I don't have to be all too abstract:

Code: Select all

session_start();

This function should be far up at the top of your script, before any output. Even though it intuitively sounds like it will start a new session, that's not the case - it will either start a new session (if none has been set up), continue the old one (if one has been set up), or create a new one with a session ID fed to it (if an old session ID is re-used past its expiry time, or someone hacks it; which sounds bad since I said the nasty h-four-letter-word, but really isn't bothersome in the least*). Suffice to say, once you have called session_start(), you can use a session.

All server-side session variables are stored in the $_SESSION array. You can add new variables to it like you would with any other array, and you can read out of them. So you'd probably want something like this:

Code: Select all

function is_logged_in() {
  $check_session = (!isset($_SESSION['logged_in'])) || ($_SESSION['logged_in']===false);
  if ($check_session) {
    if (username_and_password_okay()) {
      $_SESSION['logged_in'] = true;
      return true;
    }
  }
  return $check_session;
}

function log_out() {
  $_SESSION['logged_in'] = false;
  // Alternative, more rigorous, code if you don't want to do anything with sessions while the user is logged out:
  // session_close();
  // unset($_SESSION);
  return true;
}

username_and_password_okay() being a function of your own design.

Now, why is this good?

Firstly, your user doesn't have to send username and password each time they load the page - keeping in mind that internet traffic can be sniffed and likely will be sniffed by the malicious user, repeated password-sending (at least over HTTP) is A Very Bad Thing. Secondly, sort of as the icing on the cake, you can have the server do fairly 'heavy' computation in the username-password-matching function then (like md5()), and sessions save you from having to do it each page load, potentially saving you a lot of cycles.

* Re: bothersome & hack: it only gets bothersome if an attempted hacking either does: (a) open an existing session belonging to someone else, (b) lure someone else to using a session of their own design

See also: Understanding the Life of a Session.

[Kaiser Mors V]

I'm breaking up the bank into different pages (not just one big ubber page like the old bank).. so... login.php and createaccoutn.php and showfunds.php and transferfunds.php.. etc.. I assume the session I start at login will go on till browser close or logout is done?

[Kaiser Mors V]

How secure is a session? Can I just check the username and password once on a login page then just set a logged_in variable that pages check from then on.. or is that insecure?

basicly.. should I just use $_SESSION['loggedin'] or should I set a username and userpass variable in $_SESSION and just check it every time I load a secure page?

Logout will just kill the session outright I've decided.
session_unset();
session_destroy();

Also.. the MySQl database server password is in all my files that use it.. I don't like this.. can I centralize it in one place like set it as a constant in a file? or.. something more secure would be nice...

Can I just open the database once and put the link in the session information?

and as I'm developing I'll proly start having people test things for me... making accounts, and loging in.. moving money.. and stuff.. and trying to break everything as much as they can..


Also, and a more general non-technical question... How shall I do navigation? Put it in a frame? or some kinda side bar? maybe a lil table that sits on the side of all pages and changes in regard to what's going on....

[Kaiser Mors V]

I can put the username and password in the session cause it's stored on the server.. okey...

[Neike Taika-Tessaro]

I'm breaking up the bank into different pages (not just one big ubber page like the old bank).. so... login.php and createaccoutn.php and showfunds.php and transferfunds.php.. etc.. I assume the session I start at login will go on till browser close or logout is done?

Or it expires. (Sessions have an internal timeout.)

How secure is a session? Can I just check the username and password once on a login page then just set a logged_in variable that pages check from then on.. or is that insecure?

It's not insecure. Needing only to check username and password once is more or less the entire purpose of sessions.

basicly.. should I just use $_SESSION['loggedin'] or should I set a username and userpass variable in $_SESSION and just check it every time I load a secure page?

While you can do latter, it offers no further security, and requires computation and communication with the SQL server each page load.

Also.. the MySQl database server password is in all my files that use it.. I don't like this.. can I centralize it in one place like set it as a constant in a file? or.. something more secure would be nice...

You can put this into a separate file:

Code: Select all

define('SHIRE_DB_SERVER',"localhost");
define('SHIRE_DB_USER',"kaiser");
define('SHIRE_DB_PASS',"someconvolutedpassword");
define('SHIRE_DB_DATA',"databasename");

...then include it and use the constants...

Code: Select all

require_once('database_constants.php');
$server = mysql_pconnect(SHIRE_DB_SERVER,SHIRE_DB_USER,SHIRE_DB_PASS);
mysql_select_db(SHIRE_DB_DATA);

Can I just open the database once and put the link in the session information?

Unfortunately, not. Resource IDs (which is what's returned by mysql_connect() and mysql_pconnect()) don't survive across script-calls. Note that you can do your database server a favour by using ...pconnect() instead of ...connect(), since that basically keeps one and the same connection upright in the background - bu-u-u-u-ut you still have to connect PHP to it each script-load, so that doesn't help you preserving it in sessions, either.

(What you can do, of course, is pack the constants mentioned above into session variables. But I don't recommend that. As to why I don't recommend it - it's not a security issue, of course, but you'd end up with weird script-breaking the moment the session times out.)

Also, and a more general non-technical question... How shall I do navigation? Put it in a frame? or some kinda side bar? maybe a lil table that sits on the side of all pages and changes in regard to what's going on....

I'm personally quite fond of user style="overflow:auto;" for the non-navigation part to 'simulate' frames without actually having to break a page into several actual pages.

PHP can help you avoid duplicating code server-side: include(); include_once(); require(); and require_once(); are your friends. Include and require differ in that require kills the script if it can't find the file specified, whereas include just throws a warning. The ..._once() variants make sure that a file is only included once, so:

Code: Select all

include_once('a_file.php');
include_once('a_file.php');
include_once('a_file.php');
include_once('a_file.php');

...would include a_file on line one and ignore the other three attempted includes.

PHP file includes are funny things. You'll probably learn to view them as being relative to the initial calling script, which is levels of icky convoluted the moment you start depending on scripts being included in another across directories... I don't even want to start to explain that because it's a horrible, horrible design flaw. So, I suggest you forget that and just consistantly use:

Code: Select all

include(dirname(__FILE__)."/a_file.php");

If you really want to know why, I'll explain it, but don't say I didn't warn you.

[Kaiser Mors V]

soo.. I shouldn't just do require_once('dbman.php'); ?

[Neike Taika-Tessaro]

soo.. I shouldn't just do require_once('dbman.php'); ?

Well, I'm not sure what you're asking about - if it's about dirname(__FILE__), the constants setup, or if you should use 'require_once()' as opposed to the other three include routines. I'm just going to try and go through all three:

If you're asking if you have to use constants and then connect in each file separately, no. I try to illustrate as much as possible with my code examples - you asked about constants and includes, so I combined it. But you can of course also do:

Code: Select all

$server = mysql_pconnect("localhost","kaiser","someconvolutedpassword");
mysql_select_db("databasename");

...and then include that:

Code: Select all

include('database_connection.php');
// rest of the script goes here

If you're asking about absolute (dirname(__FILE__)) include paths instead of relative ones, bear with me for a moment. Assume you have a fun little directory structure like so:

Code: Select all

/
'-> html/
        '-> header.php
        '-> footer.php
'-> incs/
        '-> add.php
        '-> edit.php
        '-> delete.php
'-> index.php

And your index.php looks something like this:

Code: Select all

switch((string) $_REQUEST['mode']) {
  case 'edit':
  case 'add':
  case 'delete':
    include('incs/' . $_REQUEST['mode'] . '.php');
    break;
  default:
    include('html/header.php');
    echo "Invalid mode.";
    include('html/footer.php');
    break;
}

And your edit/add/delete files include something like this:

Code: Select all

include('../html/header.php');
// code here
include('../html/footer.php');

If you then call index.php?mode=add, header and footer won't be included and a WARNING-level error will be thrown, because the includes in add.php will parse relative to index.php, and not relative to add.php. That's just how PHP works includes. If you think about it for a moment, you might realise why it does this - it's the easiest way to deal with included files. But anyway, this wouldn't break, regardless from where in the directory the files are included or called:

Code: Select all

include(dirname(__FILE__).'/../html/header.php');
// code here
include(dirname(__FILE__).'/../html/footer.php');

If you're wondering about require_once() versus require(), you'll want to use require_once() for SQL connections - you won't need more than one, and if the code's executed several times by some weird convoluted include() mess, you're just blowing cycles that way. Mostly, though, require_once() and include_once() are interesting for function declarations, since if you try to declare a function that was previously declared, an error is thrown, which is always yucky.

[Kaiser Mors V]

well.. I just have the bank all in one directory.. and plan to leave it that way.. since it's not very large really.... so dirname(__FILE__) isn't really needed I guess..

if it grows large enough to need to be put in directories.. then I will..

I have 5 files right now.. and only expect maybe.. 2 -3 more... transfer, check and something I haven't thought of yet... like view transaction log... (which I haven't even gotten to yet thinking about)

[Neike Taika-Tessaro]

well.. I just have the bank all in one directory.. and plan to leave it that way.. since it's not very large really.... so dirname(__FILE__) isn't really needed I guess..

Yeah, but it's good practise to use it, and does no harm. But, up to you, of course.

[Kaiser Mors V]

There are proly a lot of things I'll have to go back and clean up... I've made a mess in some places.. (bad form!)... so once I get it all going..ish.. I start pretification, clean up and bug fixing.. and... making things are in good form...

[Kaiser Mors V]

Code: Select all

if (!isset($_SESSION)) //start a session if one isn't already going.
	 begin_session();

is something wrong here? cause... yeah... I keep setting a variable... in $_SESSION and it keeps being reset...

Code: Select all

function begin_session()
//start up a new session set initial variables we might need.
{
session_start();
$_SESSION['authorized'] = false;
}

Where I set it..

Code: Select all

	 //Do login precedures..
	 $_SESSION['username'] = $_POST['username']; //give us the username information for later.
	 $_SESSION['authorized'] = true; //they have passed inspection.
	 print('You are now logged in.<br>');

where I check it, and it gets evaled as false...

Code: Select all

if ($_SESSION['authorized'])

[Neike Taika-Tessaro]

Where does it get evaluated to false? Same page, or in another script? If it's in another script, it'll be because of this:

Code: Select all

if (!isset($_SESSION)) //start a session if one isn't already going.
    begin_session();

Your script will always execute begin_session() on script load, because $_SESSION will only be set when the function session_start() begins (if I recall correctly, that is). You'll want:

Code: Select all

start_session();
if (!isset($_SESSION['authorized'])) {
  $_SESSION['authorized'] = false;
}

If you want to make sure you're only calling session_start() once in your script with isset($_SESSION), then just put the above into the begin_session function and keep your code as is. The important bit is the (!isset($_SESSION['authorized'])) before initialising it, lest you'll be overwriting any other values you gave it each page load.

[Kaiser Mors V]

Yes... I know that... It kinda dawned on me in the shower later... this is what I get for programming before bed..

[Kaiser Mors V]

oh.. start_session() being called when there is already a session (that's been called at some point...) throws an error message..btw...

[Neike Taika-Tessaro]

Good to know. I don't think I ever tried that.

[Nick Foghorn Leghorn]

OK, I'm working on making the Definitive Micronational Index mark II (because I'm bored), and I'm stuck on a MySQL error. It used to be that I forgot a period in the concatenations, but now I dunno. I think I just need a second pair of eyes.

Assume all variables are passed from a form properly (already checked):

Code: Select all

mysql_query("INSERT INTO micronations( name, description, population, flag, active, language, mod, type, password ) VALUES( '".$name."', '".$description."', '".$population."', '".$flag."', '".$active."', '".$language."', '0', '".$type."', '".$password."' )") or die(mysql_error());

echo "New entry added. Waiting for administrator approval to continue. <a href=\"index.php\">Return to the index</a> or wait 3 seconds.";

echo "<meta http-equiv=\"Refresh\" content=\"3; url=index.php\">";

For Shireroth's entry, this throws:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mod, type, password ) VALUES( 'Shireroth', 'The Republic of Shireroth was founde' at line 1

Any thoughts?