14 comments

[ 2.9 ms ] story [ 36.0 ms ] thread

      echo "<p>You are logged in as ".$_SESSION['logged_in'].".</p>";
shiver
Hey, maybe we should be giving this guy constructive criticism instead of shivering.
The fact that people are shivering in reaction is actually very useful for potential users of this software, though I agree that it's not constructive for the author.
Fair enough on both points - but regarding the first one, will those users actually read these comments? Not particularly likely, I don't think.
That's sample code and it uses the easiest data storage readily available. Not sure what the issue is with that. Obviously you'd change it to suit your needs.
My point exactly, it's not a polished login system, it's a very basic script you can put on your page to restrict access. You obviously customise it to your needs since every application will be different.
$_SESSION['logged_in'] is only used there as it was already available to control whether the session is valid or not. There's no point making an API call when the data is already there. Anyway, it's just a quick and dirty way to integrate a Twitter login system, it should be modified to suit.
One big problem I see right off the bat: the twitterLogin() function completely breaks any page I embed this in, since if a visitor isn't logged in, all they see is a link to twitter, and then nothing since you're calling exit().

Another nitpick: if I'm logged in, and twitterCallback() is called, why is it redirecting me to / ? Perhaps my site is nested deep within a directory structure.

The script is just a basic login system, designed to be adapted to your needs since every application will differ.

I might add a login button function that will allow you to put the login button anywhere without protecting the page at the same time.

I've made a few changes, please check the new script. twitterLogin() is used to produce a login link, twitterProtect() will protect any sensitive pages. You can also set where users are redirected to.
Security note: Check out the following lines, taken from the PHP API client used by this application (https://github.com/jmathai/twitter-async/blob/master/EpiOAut...):

    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
Those lines disable certificate verification: if I can intercept the connection between this client and Twitter, I can present my own, self-signed certificate and the client will still send requests as if I were twitter.com. This completely defeats the purpose of using SSL for connections.
Not sure if you've had a somewhat popular library on Github but those two lines of code save me lots and lots of issues being opened because the library didn't work out of the box.

Perhaps I could add an optional setting to include those lines of code...but that's the beauty of open source -- so can you :).