bookmark_borderLaracast: Be Awesome in PHPStorm

I just finished most of the Laracast “Be Awesome in PHPStorm”. I didn’t do the last few because the topics are beyond where I am in my learning at this point. But I’ll be back for those later.

Like any good tool, it’s always good to learn all that it can do, and PHPStorm does an amazing amount of awesome things!



bookmark_borderHow to handle login correctly in an iPhone app that connects to a web service

I am currently designing an iPhone app. It uses a web api that I’m building in PHP. The app requires users to login.

What I am currently researching, and having a really hard time figuring out, is if there is a “proper” way to do this.

At this point, I have it so that new users can register right within the app, providing their email and a password. This password is salted (with a static salt – I know – a bad thing, but better than no salt), and then hashed before being sent to the api.

Registration, and login works fine. However, wanting to be as security conscientious as possible, I’m trying to figure out if there is a more secure, industry-standard way to do this.

The app requires the login data to live on the server, and not on the device. I may add a web interface later, and the user will need to be able to log in there as well.  Because of this, using a random salt for each app install, while more secure, as far as I can tell, will prevent web login since the salt will only exist on the device.

Someone has said use OAuth, and I would love to pursue that, but I can not find a single *simple* example of how to use it. Sure, there are plenty of high level “Here’s how OAuth works” types of tutorials out there, but it seems that no one has written a *simple* tutorial on this exact use-case.

If I could figure it out, I might just do it myself. However, I’m not sure if OAuth is the right tool in this case.

As I understand OAuth, it allows a user to login to my app using another site’s credentials, such as Google, Facebook, Twitter, etc. They authenticate through that other service, and that service passes me a token to use to identify them in the future.

If I’m understanding it correctly, that would be fine. As long as I have  a way to identify them, I don’t care how it happens. In fact, I like the idea of letting someone else handle the heavy lifting (security).

So, where do I begin?

At this point, I have no idea. I have seen several projects people have written to “encapsulate” OAuth for Objective C at a “high-level”, but they are anything but simple, and I can’t make any sense of them. Do you really need a degree in computer science just to understand this stuff?

Comments and assistance welcome.


bookmark_borderPHP Sessions: Part 4

Session Locking. Some people don’t ever consider this. I have dealt with it before in another language, so I decided to do a quick search to see what it looks like in PHP.

The basic idea is that only one process can have a file open for writing at a time. Session information is kept in files, and since you can have multiple hits coming into your web page simultaneously, things have to be processed in order, in a queue. This can cause your site to slow down under heavy load.

There are techniques you can use to help speed things up.

What I found is this:

// start the session

// I can read/write to session
$_SESSION['latestRequestTime'] = time();

// close the session

// now do my long-running code.

// still able to read from session, but not write
$twitterId = $_SESSION['twitterId'];

// dang Twitter can be slow, good thing my other Ajax calls
// aren't waiting for this to complete
$twitterFeed = fetchTwitterFeed($twitterId);

echo json_encode($twitterFeed);

For an explanation of what’s going on here, check out the original post at


bookmark_borderPHP Sessions: Part 3

Now that I know how to enable sessions, and have a better understanding of how they work, the next thing to do will be to make use of the session in some way.

But first, here are a couple notes I found in my reading:

  • The first time a user visits a page, SID will be set because the cookie doesn’t exist yet. That means that if you have the SID manually placed in your URL’s, or if Transparent SID Support is turned on, every search engine bot will pick up your links with session id’s added in.
  • The setting to make it so that cookies are required for sessions is session.use_only_cookies, in php.ini
  • If you need to add the SID manually in your URL’s, it *must* come first in the list of attributes, or it will not work.

So what to do with sessions? Obviously they’re used to store persistent data across multiple page loads. What that data is is up to the programmer.

To add an element to the session superglobal, do something like this:

$_SESSION['myValue'] = 1

In the next part, I’ll look at what can happen when more than one request is trying to access the session file at the same time.

bookmark_borderPHP Sessions: Part 2

Building off the previous part, I will now see what’s going on under the hood when a session is started.

One of the things I needed to figure out is what this means:

PHP is capable of transforming links transparently. Unless you are using PHP 4.2.0 or later, you need to enable it manually when building PHP. Under Unix, pass –enable-trans-sid to configure. If this build option and the run-time option session.use_trans_sid are enabled, relative URIs will be changed to contain the session id automatically.

I searched Google, and couldn’t find a clear explanation of what “transforming links transparently” means. Nor could I find what “Transparent SID Support” means.

Transparent SID Support simply means that when this is enabled, there is no need to pass the SID in your links manually. PHP will do it for you.

So let’s see what this SID variable is all about.

First, I’ve added code to display the PHP constant “SID”. According to the manual this variable will either be a blank string, or a string having the form “session_name=session_id”. (session_name is defined in the php.ini file)



echo '<pre>';
echo '</pre>';

echo "<br />";

echo '<pre>';
echo '</pre>';

The output of this code is interesting. The first time I ran it, there appeared to be no output for SID:

array(0) {

I suspected that there might be a cookie involved at this point, so I took a look and found this:

PHP SID cookie

So, the next thing I did was to remove that cookie, and refresh the browser. When I did, I saw this:

array(0) {


Now SID is outputting the session ID. So the lack of a cookie means that SID jumps into action.

Note that the session id’s are different. This makes sense. If you clear your cookies, you lose your session. If your cookies are disabled, SID will be there as a replacement. Note however that passing the SID in the URL can leave you more vulnerable to XSS related attacks.

Next, I refreshed my browser page again, and when I did, the SID output went away, and the cookie reappeared. As expected, the cookie value was the same as the SID from the previous refresh, indicating that PHP has successfully set a cookie, and will now manage the session in that manner, as long as I don’t delete it or disable cookies.

Transparent SID Support is disabled in newer versions of PHP by default because it’s not a good idea to pass the session in the URL string. Basically, if you are using sessions, you should require cookies if you want to be as secure as you can.