Rachman Chavik

Perhaps you meant `cakephp/acl` mark?

Wouldn't that break developers environments who run the app under a UserDir, eg: http://server/~dev1/myapp http://server/~dev2/myapp http://myapp/

Mark, I will most definitely positively sure that I will need this feature sometime soon. So I went ahead and implement it. http://github.com/rchavik/asset_compress/commit/e463feadcc145d8f33b9c83f6117c852b7ce46df. Untested. But may prove useful.

I haven't used AssetCompress in a while, and I don't have the resource to polish this further. Recently, we either use an external build pipeline like compass, or just simple...

_sigh_ needs more work and testing

I've continued working on this and making more changes here. So far, I come to the following conclusion: - `Client.client_secret` can be encrypted, while others secrets like `access_token`, `refresh_token`, `auth_code`...

This depends on the fix-client-secret PR. The actual diff is: ca91a4aa9f3b5f8351d4e7b2728823c81cfd3a02...1913409d7c3c398f117f0d5f4053d7c144f4a983 The reroll is backward incompatible and contains the following changes: - No more config `OAuth.encrypt`. All client_secrets must be...

> The iv is derived from the key (the salt in the current implementation). The IV does not need to be secret, but does need to be unique (as Cake...

> Why can't we just use Security::rijndael with the random iv? Since using random IV will cause encrypted value of `$access_token` be different each time, the proposed implementation for `OAuthUtility::getAccessToken($oauth_token)`...

> > We will need to know the client_id to get the encrypted access_tokens.access token. > > Then decrypt it to compare against $oauth_token from the request. > > The...