In production, you'll usually deploy your SproutCore app as a static file, so all you have to do is arrange for your users to hit that URL (which out of the box is configured as /static, but could be anything).
In development mode, though, you want to be regenerating your client on the fly by serving it dynamically from sc-server. To use your app, you talk to http://localhost:4020, and if you want your client to communicate with a backend server, you configure the "proxy" setting in sc-config. Thus when the Sproutcore server gets a request for "/gadgets", it proxies that request to your local development server.
For some kinds of apps, this works well. For OtherInbox though, everything the Sproutcore app does requires you to be signed-in and have an active session with the Rails application server. This caused all kinds of cookie problems, probably because of same origin policy (e.g. my Rails app running at otherinbox.dev was issuing cookies that were somehow getting mangled by the proxying process).
Here's what I solved the problem. Check out my local Apache setup for details about the whole stack:
See how that works? When I load http://otherinbox.dev/app in the browser, Apache proxies that request to sc-server, which dynamically generates my Sproutcore client app.
When components of that app make requests for other parts of Sproutcore, using the /static URL, Apache also proxies those back to sc-server.
When the app makes requests for anything else, those requests get proxied by Apache to the Mongrel I have running the Rails code. Because my Sproutcore app is making REST calls to the backend, this ensures that anything the Sproutcore app asks for from my server gets proxied properly, in this case to localhost:3000.
As soon as I did this, all of the cookie issues were done. You'll also have to add some application-specific code about how you want to force logins if the user is not already signed-in. In our code, I just check for a logged-in cookie, and if it's not there, we open up the URL for a signin window.