Berk D. Demir's dashboard

Integration with su.pr even just for simple url shortening will be sufficient at first. Su.pr offers a more customized shortening experience for the user thus ability to supply login and api_key for authenticated ReST call would be super cool. Same ability can be extended to bit.ly and other services too.

!mmalone:

Authentication and Authorization are two discrete activities as you know. There's nothing barres you to use existing usernames (and let them be changed by user anyitme) while using OpenID for authorization.

OpenID and OAuth doesn't expose a conflict of interest in anyway...
While using OpenID for authorizing access to users for site access, it's perfectly possible to use OAuth for authorizing "on-behalf access" to API.

OAuth establishes a trust channel between the API provider and consumer. There's no point to involve "Identity Provider" after establishment of API trust binding. And there's no requirement in OAuth for API provider being also the Identity Provider... In contrast, OpenID access "requires" contacting OP whenever user claims an ID. So responsibilities are well defined in here.

API Provider creates the trust binding to a consumer with OAuth for one time than let's access by authenticating requests every time without user interaction. Whenever user decides to break the coupling, an interface of API provider helps the user to provision his/her request.

Real user access to site via OpenID is completely different though...
"Relying Party" (API provider web app in the former scenario) MUST request the proof of the ownership for claimed Identity everytime. So OP should be involved in every authorization action.

Technically OpenID and OAuth can have overlapping specifications but their use cases are completely different. No end-user should care about OAuth and access granting process shouldn't be more complex than just a confirmation screen. On the other hand, in OpenID access case, user should be aware of his/her "Identifier" URI to claim an identity.

It's nice to hear Pownce team are involved in the communities of both OpenID and OAuth. I'm sure this will foster a near-perfect implementation of both standarts in Pownce, over the time.

...But I think, -with current standards- deployment of these two technologies are not mutually exclusive in anyway.

Computer Science is here to rescue and I'm sure Leah is one who has a good grasp of it.

http://en.wikipedia.org/wiki/Denormal...
http://www.objectarchitects.de/Object...

If disk space turns out to be expensive in this trade-off, please inform people. We'll go 'Pro' just for kicks or donate some.

I guess I found out the reason of "Please enable cookies and try again" error with Firefox.

Pownce uses Google Analytics (GA) for web statistics. To enable this feature, a remote JavaScript file is loaded ("http://www.google-analytics.com/urchin.js"). Urchin (the software behind GA) basically sets 4 different cookies. (named: __utma, __utmb, __utmc, __utmz).

After the gory details, here comes the root cause. Two different very popular Firefox add-ons, with specific configurations can block Google Analytics. The first one is Ad Block Plus with 'ABP Tracking Filter' subscription (which barres the downloading of Urchin JavaScript) and the other one is CustomizeGoogle add-on configured to block sending cookies to GA (Tools -> CustomizeGoogle Options -> Privacy -> Don't send any cookies to Google Analytics)

Although the client could set session cookie named "sessionid", Pownce seems to assert Google Analytics cookies first.

That's why the login window spits out "Please enable cookies and try again" error I guess.

This's an ugly problem though. If my theory about checking Urchin cookies (__utmX) is true then I kindly request the reasoning behind this assertion.

Possible workaround for this problem:

Short answer:
Don't mess with Google Analytics. Leah loves it and you're not allowed in without it.

Long answer:
Disable the particular Ad Block filters which block GA. Here are the lines from my set of subscriptions

Lines from ABP Tracking Filter Subcription:

/urchin.js

.google-analytics.

/__utm.js

/__utm.gif?

Lines from Filter von Dr. Evil Subscription:

.google-analytics.com/

After fixing Ad Block filters, disable "Don't send any cookies to Google Analytics" option of CustomizeGoogle add-on.