AJ ONeal <coola...@gmail.com> writes: > A user which exists on one site must be able to use the API of another site > without logging in to that site. I think a token mechanism is the way to go > but I want input. […] > P.S. What do you call XSS when you're talking about proper XSS rather than > malicious XSS?
Rather than cross-site, the general term for this problem is cross-domain scripting, request, ajax, proxy, json, &c. A common solution – cross-domain proxying – is to have the primary site (JT) proxy the browser's requests to the secondary domain (CM). Another approach is to use dynamic insertions of the <script src="http://secondary/script.js";> tag to allow pages served from the primary site to communicate with javascript from the secondary domain. Since the script returned for the tag was served from the secondary domain, the same-origin policy allows that script to communicate with the secondary site. The mix of primary- and secondary-domain scripts running on the page can communicate via global variables or whatever (clientStorage, WebWorkers, events, &c.). In such a way they can cooperate to satisfy the full functionality. People shy away from this solution on the world-*wide* web because it means letting a perhaps *untrusted* secondary domain insert arbitrary, perhaps malicious code into your site, which *then* becomes a XSS hole. But if you control both the primary and secondary domains, you don't have that risk. http://snook.ca/archives/javascript/cross_domain_aj/ > The proposed solution > > 1. John submits his credentials to JT. > 2. John is validated. > 3. JT makes a request to CM using curl, sending a valid username and > password (and possibly the IP address will be checked). > 4. CM sends back a token (which CM will store in a database or file). > 5. JT then hands that token back to to the browser. > 6. The browser, receiving the token, makes a request to CM to login using > the token. > 7. CM checks the token's timestamp, checks the token, starts the session, > and deletes the token. > 8. John inputs some new data and submits it to CM via AJAX through the JT > interface. Maybe you mean something different than I read by "through the JT interface" in step (8), but steps 5-7 are mutually exclusive with 8: if 5-7 are used (likely via the <script> hack), then you don't need to proxy the request through JT in 8. But, if you do proxy through JT, then only JT needs to keep track of the token/auth with CM¹, so you don't necessarily need to send it back to the browser. ¹ though it might be a more scalable implementation of such a proxy if JT really does hand the token back down to the browser, and let the browser send it back up to JT for JT's proxy-request to CM. Then JT can remain stateless. If the token is secure, -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgpvaXqlWzWOP.pgp
Description: PGP signature
