I am using $_SERVER[‘REQUEST_URI’] to grab the URL…which is this:
/Appointments/Administrator/events.php/219
My question is what string function I should use to grab the number after /events.php/.
In the example above is 219…but it can be any number.
Seems a bit strange just having a number but here is some information on parse_url which I do not think will help you.
I would probably use explode()
Well,I am trying to build an events calendar based on this tutorialhttp://blog.shinetech.com/2011/08/05/building-a-shared-calendar-with-backbone-js-and-fullcalendar-a-step-by-step-tutorial/.
It uses a RESTfull interface and the number in the URL is an event ID.
Anyway…I will try your reccomendations.
Yes, explode and end should do it.
<?php
//test
$url = "/Appointments/Administrator/events.php/219";
//$url = $_SERVER['REQUEST_URI'];
$parts = explode('/', $url);
$number = end($parts);
?>
Just be sure to validate/escape/bind any value returned.
Hi designtrooper,
Have you thought about using a micro framework for the API? It would take care of this sort of thing out of the box.
I’ve used the Slim framework before and found it to be lightweight but quite useful. A basic example of using it to create a route like you wanted would look something like this:
<?php
$app = new \\Slim\\Slim();
$app->get('/events/:id', function ($id) {
//Retrieve and return your event
});
// You can then add other routes to deal with creating new events etc:
$app->post('/events', function () {
//Create event
});
Here is yet another method of extracting just the latter number:
$url = '/Appointments/Administrator/events.php/219';
$x = strrchr($url, '/');
$y = substr($x, 1);
// combined result
$z = substr(strrchr($url, '/'), 1);
echo '<br />' .$url;
echo '<br />' .$x;
echo '<br />' .$y;
echo '<br />';
echo '<br />' .$z
Output:
/Appointments/Administrator/events.php/219
/219
219
219
Any more solutions?
Yes the above will do it…thanks.About validating etc.nothing is returned…the code is used to delete an event from the db(using the provided ID…219 in this case).
The only thing that gets returned is a boolean true that the deletion actually took place-false otherwise.
If I was going to use a framework I was thinking laravel…but I am reconsidering now because I have heard slim elsewhere to.
Overall…do you think is better to use a framework instead of writing the code my own?
I want to hear some views.
Thanks
I think that depends. If you’re doing it as a learning exercise then it can be beneficial to write all the code yourself, at least so you can appreciate the stuff that a framework usually takes care of for you, and to have some idea of how it works behind the scenes (to this end, it’s also good to read through the code of some different frameworks to see how they approach common tasks).
On the other hand, once you’re past the learning curve of a particular framework you can be a lot more productive, as you avoid writing a lot of ‘boilerplate’ code for every project. I’d also definitely look into a few of the most popular ones if you want to improve your job options as a web developer (Symfony2, ZF2, and Laravel being some of the most popular).
As for using Laravel for a project like the one you’re doing, there are some pros and cons. On the plus side, Laravel seems really nice to work with (I’ve just started playing around with it myself) and is certainly very popular, so it’s easy to find tutorials and bundles (modules) for it. It also has some nice features that make it easy to put together a RESTful API. On the con side, the codebase is quite large (roughly 18mb for the base install)… it includes a lot of stuff that might be overkill for a simple API that’s serving as the back-end for a JS app. If you were building an API that was going to get heavy use, I suspect Slim might give you better performance from being rather lightweight in comparison.
About validating etc.nothing is returned...the code is used to delete an event from the db(using the provided ID...219 in this case).
Just be careful and validate that it’s really just a number anyway.
Consider an SQL statement like this:
DELETE FROM Table WHERE id=$id
and the URL:
http://www.somesite.com/Appointments/Administrator/events.php/219%20OR%20id%20>%200
which will give you the following SQL statement:
DELETE FROM Events WHERE id=200 OR id > 0
Now your Events table is empty! 
Of course, you should use “prepared statements” to prevent it, but we’re never too careful
Yes…but the ID is not entered by the user (from a form for example)…the app handles that.
How can this be tampered…I do not know a lot from security.
Lastly…I have some questions about the Slim framework but I am going to open separate topic for that-the purpose of this topic was not for that anyway.
Thanks
Well, I could sniff the traffic on my internal network, see that your app calls this url and use the url in a normal browser.
Ever heard of CSRF? 
Some people/bots test random URIs as well to see if they hit anything (worth exploiting), as anyone who has ever looked at server logs hosting a public site would tell you. So better be safe than sorry!
Since its a number & your code expects a number its fairly easy for you to validate. Just check if its a number or not & pass the value through intval() and you will get a safe value from it. So it’d be something like:
if ( is_numeric( $number ) ) {
$number = intval( $number );
} else {
$number = 0;
}
if ( $number > 0 ) {
//do the deletion
} else {
//throw an exception or hold the silence
}
What you say certainly makes sense.I will look at the validation aspect too.
Thanks
There is a basic rule of thumb - never trust a value that is not hardcoded in your code, always validate & sanitize. If you follow this simple rule, you should be golden as far as simple/dumb attacks are concerned.
Well,of course I know this rule.I always implemented in forms.
But it is the first time I am working with URLs/REST and I do not quite know what are the security implications here.
It is new area for me.
Forms, URLs - the rule applies everywhere. Like I said, if a value is not hard-coded into your code, you should not trust it.