On the Paragon Initiative site they've posted a new tutorial sharing a method for creating "one login to rule them all" for your PHP-based applications. The goal is to make one system that can provides a single authentication point and secure credential storage.

Problem: You want to create a system whereby when a user authenticates to example.com, they're also automatically logged in at foo.com, bar.com, baz.com, and any other domains that you decide to add to the list at a later date. Okay, great, that seems straightforward, except there's a complication: The Same Origin Policy prevents you from getting/setting cookies on domains other than the one you control.

[...] Let's narrow it down a little bit further: Unlike a situation where e.g. "Login with Facebook" would be appropriate, you control all of the domains. They just happen to be different, so the Same Origin Policy kicks in. For simplicity, feel free to assume they're on the same server and application codebase, but you have a multi-site architecture in place where some of the sites have a different domain name.

Let's work around this limitation with as few moving parts as possible.

He then shoes how to use libsodium (via the Halite wrapper) to secure your credentials (passwords) and hooking it into a custom API endpoint that takes in a hex-encoded JSON string and a signature for the payload. He then expands this to provide "automatic login" handling making use of another endpoint to fetch an image to and log in the user by passing it the payload and signature values. He ends the post with a few security concerns around using this method and some things that it assumes are correct (and robust enough).

In his latest post David Müller covers some of the things to consider when working with cross-domain ajax requests including CORS and iframes.

As it is widely known, AJAX Requests are only possible if port, protocol and domain of sender and receiver are equal. [...] Having this cleared out, we will cover ways around this restriction.

He covers three main approaches to allowing these cross-domain requests (and some of the security implications that can come with them):

• CORS (Cross Origin Resource Sharing)
• JSONP (Javascript with a local domain callback)
• Iframes

He also briefly mentions things like window.postMessage (HTML5) and the use of a backend script to proxy a request into your application's local code.

Ever been frustrated by the fact that your javascript code can't make JSON requests to sites under other other domains? Well, WebSpeaks.in has some happy news for you in the form of JSONP.

Well.....finally i have worked out how to post cross-domain data which is restricted by browser's security policies. What is it?? This will be used for posting AJAX requests via java-script to any web-service or web-page in any DOMAIN and also get back the results from there.

JSONP allows you to call a URL outside of the domain the script is running from with a callback. This callback lives in the calling script so, technically, it never leaves that scope. There's lots of other resources out there to help you implement it in your own code including jQuery and Prototype JSON handling.

SitePoint has posted the second part of a series from Jordan Knight about creating a Twitter client by combining Silverlight and PHP (part one is here).

The application that we’ll build in this article will allow you to enter a Twitter search term, and display the tweets received in Silverlight. Unfortunately, this process isn’t as simple as loading a URL from Silverlight, because of something known as cross-domain access policy.

He talks some about the problem that this cross-domain access can cause for your scripts and how he used PHP to solve it. He created a simple web service that his Silverlight application could query in the same domain. This service did the call to Twitter and returned back the results to the waiting Silverlight app.