Affected versions: 1.7, 1.8, 1.9
Not affected: latest (1.9.1) and older than 1.7 (I hope nobody’s still running them!).

–

The issue

In a nutshell: a typical API request, with data returned as “js”, the job publisher’s email address is revealed, as well as the secret “auth” hash used for editing/deleting jobs (without an account). A typical API request:
/api/api.php?action=getJobs&type=0&category=0&count=5&random=1&days_behind=100&response=js
e.g. http://www.jobberbase.com/api/api.php?action=getJobs&type=0&category=0&count=5&random=1&days_behind=100&response=js

Inside the jobs array/JSON, you’ll see that each job has 2 fields that shouldn’t be there: auth and poster_email.
*auth* is the auth string used in URLs for editing and deactivating job ads.
*poster_email* is the actual email address of the advertiser.

Bad.

The fix

In your _includes/class.Job.php:

a) Search for method ApiGetJobs. On line 501, there should be a while-loop after the big SELECT for jobs. Replace the contents in that while-loop with:
$current_job = new Job($row['id']);
$job = $current_job->GetInfo();
unset($job['poster_email']);
unset($job['auth']);
$jobs[] = $job;

b) Do the same for method ApiGetJobsByCompany (while-loop should be on line 541 after you made the change on 2a).

====

We’re sorry for not picking this up earlier and we hope your site wasn’t affected in any way by this breach.

If you have any further questions about this issue or other security concerns, please don’t hesitate to write back!

Later update: skip this and get the fix »

–

Hi guys,

We discovered a potential security breach in the jobberBase codebase, which would allow an attacker to mess with the database.

This affects versions 1.9, 1.8 and possibly 1.7.

Therefore, if you run a jobberBase site, we ask that you send us an email to hello@jobberbase.com, tell us your site’s URL and prove that you own it. Then, we’ll tell you what the problem is and offer you several ways to fix it.

We’ve chosen to tackle this problem like this because it’s quite sensitive — a public announcement of the issue could have negative effects on jobberBase-powered sites.

Thank you for your understanding!

Stats? What stats?

Well, I’ve created a page that displays some useful overall information about the site.
Assuming your URL is http://localhost/jobberbase/, the stats can be accessed at http://localhost/jobberbase/stats/.

You probably don’t want other people to see them, so you might want to protect the page somehow. On jobber.ro, I use an extra param (/stats/EXTRA_PARAM/) based on which I perform a basic authentication (if EXTRA_PARAM exists, display page). :p

What stats are available?

• A list of the latest job applications + total no. of apps + maximum apps per day, in the past 30 days + average apps per day, in the past 30 days.
• List of performed searches on the site + total no. of searches + max searches per day in the past 30 days + avg apps per day in the past 30 days.

On jobber.ro we also track the site widgets, like this:
Whenever someone clicks on a job ad she sees on a 3rd party site (that displays the jobber site widget), we save the referrer. This way, we know EXACTLY how many people actually used the site widget and how popular it is on their sites .

Metrics is always good!
Enjoy!

In the root directory of jobberBase, there’s a cron_maintenance.php script that you should run with cron (or Task Scheduler, on Windows). On jobber.ro, I have that script running every night.

Default maintenance

For now, what the maintenance script does is delete temporary and inactive job ads.

What else can you do

The standard job-board behavior is to allow an ad to be active for a number of days (30, for most of them). If you wish to implement this in your jobberBase-based site, you could use the cron_maintenance.php to deactivate older ads and/or notify publishers with 2-3 days before this deactivation…

I’m guessing that an OPTIMIZE TABLE jobs; would also be useful, from time to time .

Some people reported they missed the .htaccess file from the downloaded distribution.
If this is you, here are the contents of a .htaccess file you should place in jobberBase root dir (together with index.php and config.php):

RewriteEngine on
Options +FollowSymlinks

ErrorDocument 404 /page-unavailable/

Additionally, I’ve added a htaccess.txt file in the distribution, so you can rename it into .htaccess.

1. Download the latest version from jobberBase.com and decompress it.
2. Make sure you have PHP 5+ (with mysqli extension enabled) and MySQL 4.1+ installed on your server. Also, Apache module mod_rewrite has to be enabled and overriding default settings with .htaccess need to be allowed.
3. Can you see the .htaccess file in your downloaded files? Make sure it’s there.
4. Create a new database and import __db/jobberbase.sql into it.
5. Following directories need write permissions:
   • /uploads (uploaded resumes are temporary stored here)
   • /_templates/_cache (smarty cache)
6. Open config.php and update the following constants so they suit your environment:
   • DB_HOST
   • DB_USER
   • DB_PASS
   • DB_NAME
   • JOBBER_URL
   • _APP_MAIN_DIR
   • NOTIFY_EMAIL
   • ADMIN_EMAIL
   • SITE_NAME
7. If you can’t see the .htaccess file or actually don’t have it, rename htaccess.txt into .htaccess.
8. If your host doesn’t offer the mysqli PHP extension (find out from phpinfo()), you can use a mysql wrapper instead.
   Open config.php and just replace require_once '_includes/class.Db.php' with require_once '_includes/class.Db.MySql.php' (thanks to Emil Sirbu for this).
9. That’s it, open up a browser and type in the URL (e.g. http://localhost/jobberbase/)!

Does this work for you?
Do you have a special environment that needed extra tweaking? Would you like to share?

Assuming you’ve installed jobberBase and you’re ready to start hacking and adjusting it to your needs, you’ll soon find out the posting a job ad might not work as you first expect it to work.

So let me draw it for you:

And this is what it means:

1. You post a job ad.
2. The system checks if there are any other ads you’ve previously posted with the same e-mail address.
3. If there aren’t any, your ad goes into “pending” mode and the administrator receives an e-mail with this new ad. He has to manually activate it, in order for the ad to be published.
4. If, however, your address is found in the database, this new ad will be published instantly.

I chose this solution because it was very fast to implement and it still is very efficient. Most database administration operations are done directly in phpmyadmin, but others (activate/edit/deactivate) from the e-mails jobberBase sends to the admin.

However, the system is pretty flexible once you get the hang of it.

Have fun!