On the AWS PHP SDK blog there's a new tutorial posted showing you how to use the multipart uploader with client-side encryption via the library.

The AWS SDK for PHP released support for multipart uploads with client-side encryption in version 3.48.0 via the S3EncryptionMultipartUploader. With client-side encryption, data is encrypted and decrypted directly in your environment. This means that this data is encrypted before it’s transferred to Amazon S3, and you don’t rely on an external service to handle encryption for you.

Multipart uploads are designed to improve the upload experience for larger objects. With it, you can upload objects via parts that can be uploaded independently, in any order, and in parallel. You can use a multipart upload for objects from 5 MB to 5 TB in size.

The article then starts you off with the requirements you'll need to follow along and some sample code to get the client up and running. The code then shows how to perform the file upload, making use of a file stream (via fopen) to pull in the contents of the file. The tutorial finishes by describing some of the other fields that can be used with the client and links to other SDKs that support this same functionality in other languages.

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.

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.

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.

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.

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).

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).

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.

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.

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".