Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Codevate.com:
Securing client-side public API access with OAuth 2 and Symfony
Jul 18, 2016 @ 12:30:26

On the Codevate.com blog there's a tutorial posted by Chris Lush showing you how to secure your client-side public API with OAuth 2 (based on the Symfony platform).

Say you’ll be developing a web application for a customer to create and manage restaurant bookings, exposing restaurant information (name, opening times, menu contents etc.) and booking creation as RESTful API endpoints, which are consumed by secure admin backend. You’ll need to authorise access to the API, but there is no end-user involved since the web app is its own resource owner, so the previous flow doesn’t apply.

[...] However, you also need to develop a booking widget that will be embedded in a company or restaurant’s website for visitors to use. In this case, the client-side is no longer trusted enough to share the OAuth client secret that’s required to authenticate with your API. [...] We encountered a similar use-case for a client project recently, and this blog post details the steps taken to address it.

He then shows how to integrate the FOSOAuthServerBundle bundle into your current Symfony-based application and the updates you'll need to make to your security.yml file. He includes the code needed to create a "client" and associating it with a company already in the customer list. Next is the creation of access tokens and linking them to the restaurants in their system (a unique identifier to use externally for the restaurant rather than an ID). He shows an example of handling the token requests and the code/config changes needed to set it up. Finally he talks about scoping API requests down to certain functionality and an example cURL call to the API to show the results of it all combined.

tagged: clientside api access security oauth2 symfony tutorial bundle

Link: https://www.codevate.com/blog/12-securing-client-side-public-api-access-with-oauth-2-and-symfony

Tillate Blog:
Clientside Cache Control
Nov 14, 2008 @ 13:00:14

On the Tillate Blog today there's a new post from Leo looking at how you can give clients back the control on when your cache refreshes.

We worked hard on the right caching strategy over months now. But there are still caches that do not get invalidated right or are cached too long and we still get complaints from our users. So we decided to integrate a feature that allows certain users to invalidate the cache on the server side. The first idea was to add a link to every page that will append a GET-parameter to the site and then avoid the cache.

He used the apache_request_header function to get the current request's headers and noticed that they included a cache-control header. By changing up this on the client-side, it allows the site visitor to "force" an update to the information if your application pays attention to it.

tagged: clientside control cache request header cachecontrol

Link:

SitePoint Server Side Coding Blog:
Cache it! Solve PHP Performance Problems
Nov 09, 2007 @ 19:16:00

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

tagged: caching serverside clientside pear cachelite package partial caching serverside clientside pear cachelite package partial

Link:

SitePoint Server Side Coding Blog:
Cache it! Solve PHP Performance Problems
Nov 09, 2007 @ 19:16:00

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

tagged: caching serverside clientside pear cachelite package partial caching serverside clientside pear cachelite package partial

Link:

Raphael Stolt's Blog:
Handling JSON responses on the client side
Jun 06, 2007 @ 07:41:00

In a previous post, Raphael Stolt showed how to create a simple application that handled the transmission of a JSON-formatted message from the Zend Framework's Zend_Service component (translating XML to JSON in the process). In this new post today he shows the other half of the equation - how to handle the JSON messages on the receiving end.

In this post I'd like to show how to unpack the JSON response and render a visual representation by utilizing the Template class of the Prototype JavaScript library.

The code is all Javascript but it's a good example of how to break down the request and output a simple list format of the contents to the page (record "shelf" and record information).

tagged: json response clientside template prototype javascript json response clientside template prototype javascript

Link:

Raphael Stolt's Blog:
Handling JSON responses on the client side
Jun 06, 2007 @ 07:41:00

In a previous post, Raphael Stolt showed how to create a simple application that handled the transmission of a JSON-formatted message from the Zend Framework's Zend_Service component (translating XML to JSON in the process). In this new post today he shows the other half of the equation - how to handle the JSON messages on the receiving end.

In this post I'd like to show how to unpack the JSON response and render a visual representation by utilizing the Template class of the Prototype JavaScript library.

The code is all Javascript but it's a good example of how to break down the request and output a simple list format of the contents to the page (record "shelf" and record information).

tagged: json response clientside template prototype javascript json response clientside template prototype javascript

Link:

Zend Developer Zone:
PHP Security Tip #14
Mar 21, 2007 @ 16:13:00

The Zend Developer Zone continues their great series of tips today with the latest - #14 - a tip concerning the consideration of the overall security of your application (there's a mouthful).

Almost any application running PHP on the back-end uses web technologies for it's front end. Many developers who think hard on PHP security, don't spend a thought on front-end security for their application.

The specific example they give is a frontend issue, a Javascript cookie. Ensure that any data you put inside a cookie is safe. No matter what, do not put anything sensitive in its contents.

tagged: securitytip clientside application javascript cookie securitytip clientside application javascript cookie

Link:

Zend Developer Zone:
PHP Security Tip #14
Mar 21, 2007 @ 16:13:00

The Zend Developer Zone continues their great series of tips today with the latest - #14 - a tip concerning the consideration of the overall security of your application (there's a mouthful).

Almost any application running PHP on the back-end uses web technologies for it's front end. Many developers who think hard on PHP security, don't spend a thought on front-end security for their application.

The specific example they give is a frontend issue, a Javascript cookie. Ensure that any data you put inside a cookie is safe. No matter what, do not put anything sensitive in its contents.

tagged: securitytip clientside application javascript cookie securitytip clientside application javascript cookie

Link:

SitePoint PHP Blog:
It's official: Javascript sucks harder than PHP
Oct 11, 2006 @ 09:35:00

It's official - Javascript sucks. Well, at least according to Harry Fuecks and the group from the last WebTuesday meeting.

The surprise outcome of last nights webtuesday - Javascript sucks harder than PHP. I still can't quite believe it. Maarten took the PHP corner against me in the Javascript corner, both of us shamelessly advocating each language under various headings.

1 minute max per topic—no outright lies although often bordering on truthiness. Verdicts provided by the audience, based on who could shout loudest from a choice [ranking].

Of course, Harry does comment that the comparison is a bit unfair (server versus client side), but there are alternatives for both (client-side PHP and server-side Javascript) so make a foundation for enough of a comparison. At the end of the night, though, the results of the votes were conclusive - Javascript was in worse shape than PHP, though the winner was "he one that came out hurting less".

tagged: javascript sucks ranking scale serverside clientside javascript sucks ranking scale serverside clientside

Link:

SitePoint PHP Blog:
It's official: Javascript sucks harder than PHP
Oct 11, 2006 @ 09:35:00

It's official - Javascript sucks. Well, at least according to Harry Fuecks and the group from the last WebTuesday meeting.

The surprise outcome of last nights webtuesday - Javascript sucks harder than PHP. I still can't quite believe it. Maarten took the PHP corner against me in the Javascript corner, both of us shamelessly advocating each language under various headings.

1 minute max per topic—no outright lies although often bordering on truthiness. Verdicts provided by the audience, based on who could shout loudest from a choice [ranking].

Of course, Harry does comment that the comparison is a bit unfair (server versus client side), but there are alternatives for both (client-side PHP and server-side Javascript) so make a foundation for enough of a comparison. At the end of the night, though, the results of the votes were conclusive - Javascript was in worse shape than PHP, though the winner was "he one that came out hurting less".

tagged: javascript sucks ranking scale serverside clientside javascript sucks ranking scale serverside clientside

Link: