The Google API (or things like calendar and Docs) has a handy feature where any code can point to a generic URL and get the info for the user currently logged in to that session.
I would like something similar, but without relying on OAuth or RESTfulness, or user-approval via token.
Essentially a user will log in using the same authentication method they use for several other services/areas of the site. All of these sites use the same cookie, so logging in to, say, check your schedule, will get you into most other areas of this very vast site without re-authenticating. After checking your schedule, you can go to a totally separate part of the site to do something like upload pictures to your profile page, whatever.
So this webservice would be behind the same authentication wall. What the developer/client should be able to do is make a server-side request like current_user_bday(), without any need for knowing what the user's login ID is or anything dealing with the cookie.
For a better picture of what I have in mind in terms of the service, see my last question.
So I'm wondering if:
Do server-side requests (specifically to web services) always pass the session cookies in that request?
Is the web service considered part of the end-user's session in such a way that it can query for the cookie the same way the original server can?
If none of the above (I think they might be the same question...) what would be the most simple and safest way to achieve what I have in mind.
To be clear, I would like the requesting server to simply use a method like get_bday() and that is IT. I want to avoid the developer from having to learn how to deal with the cookie, pass the cookie manually, etc, and I wan to avoid being held responsible (or the service being held responsible) for encouraging potentially security-threatening practices.