When it comes to working as a back-end developer you will need to automate some mechanical tasks. I like to use the cron function in unix to fire off processes at regular intervals.
sudo cron startcrontab -e (select an editor)* * * * * date >> /home/ubuntu/workspace/times.txtmore times.txt (try this again after you've moved on a little)We started the cron process which looks at the crontab every single minute to see if there is a job that needs to be done. The five stars represent: minuteofhour hourofday dayofmonth themonth dayofweek. Note that days of week 0 is Sunday 1 is Monday and so on. Wikipedia vis Stackoverflow stolen picture:
* * * * * command to execute
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ │
│ │ │ │ └───── day of week (0 - 7) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0)
│ │ │ └────────── month (1 - 12)
│ │ └─────────────── day of month (1 - 31)
│ └──────────────────── hour (0 - 23)
└───────────────────────── min (0 - 59)
If you want to run a script less often or at specific intervals you can specify a star as the values you want. For instance 20 * * * * /usr/bin/python /home/ubuntu/workspace/script.py will run the python script script.py every hour at the 20th minute. I can comma separate some specific values like: 10,40 * * * * commandhere which will do the command at *:10 and *:40. You can also do */n to do something every nth time, like */2 * * * * command which runs every other minute.
Tiny Task A: Create a job that runs three times an hour every hour.
Tiny Task B: Create a job that runs every business day (Monday-Friday) at 3:15pm
Some warnings. Setting the timezone in cronjob is system dependent and in some cases easy other cases hard. In any script which is going to be called form a cronjob use absolute paths, the job is run from a restricted shell without all of the same environment variables. You should run a couple of trials when you start a fresh ongoing cronjob.
Other than that, anything you can do from the shell you can schedule. Like integrity checking or backing up a database or creating reports.
So I feel like I'm behind in these notes right now and you guys are great. So let's try the rest of this class in start-up style. I'm going to set 4 useful tasks that we should be able to do. Then, given some documentation, we will knock them out as a class. When you make progress share snippets on piazza!
So far I've preferred to have your code just work despite being insecure. That was a choice to minimize the number of obstacles you would need to tackle at once. Now that you are all proficient DBers let's turn to some administration tasks.
We mentioned briefly the ability to set user permissions in your mySQL databases. The notes are from class3, the mongo version has a similar story.
Let's work through this guide to set up an admin user. After that make normal users.
In firebase there is a "rules" key that has access control for the rest of your data. Here is the introduction to these rules. Note that we are restricting access before the authentication step, based on an eventual auth.uid. Authentication is handled here in the auth guide. Full details are here.
So a worst case scenario for your app is this: when you ask a user for some data, like their name, that clever user can pass you something nasty like ' OR 'x'='x to get a guaranteed true in the where clause. Or worse Bobby Tables you.
It's pretty easy to avoid this problem. Never pass raw user input directly into your queries! (Mongoose is OK with this, since it is all in the filter by definition.) When using PHP the right way to set this up is something like:
$myQuery = $databaseHandler->prepare('SELECT customer_name, telephone_number, account_id FROM BananaStandUsers WHERE customer_name = :username');
$myQuery->bindParam(':username', $userNameInput);
$myQuery->execute();
For this task, create a PHP to SQLite connection that is not secure then hack yourself. Then fix it and see how it goes.
In your future lives there will always be some sort of binder like this in various drivers for databases.