Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide way to supply cookies to be used during deployment #283

Closed
jmcphers opened this issue Jul 31, 2018 · 4 comments
Closed

Provide way to supply cookies to be used during deployment #283

jmcphers opened this issue Jul 31, 2018 · 4 comments
Milestone

Comments

@jmcphers
Copy link
Member

Some proxies use authentication cookies to validate requests. If a user already has such a cookie, they have no way to use it when deploying content from RStudio; it's not even possible to hack it together using e.g. .Rprofile since the R process that does the deployment uses --vanilla.

At a minimum, we'd need to expose and document rsconnect::storeCookies or a suitable front-end thereof to make this work, and update RStudio so that it can inject cookies into the R process doing the deployment. Alternately (or additionally) we could add some hooks to make it easier for arbitrary code to run prior to deployment inside the R session, to make it possible for organizations to resolve these kinds of edge cases on their own.

@jmcphers jmcphers added this to the 0.9 milestone Jul 31, 2018
@trestletech
Copy link
Contributor

For Connect, I think our long-term strategy on these fronts was to move non-interactive use-cases to API keys. Is there compelling reason to value cookies over API keys?

@jmcphers
Copy link
Member Author

Well, aside from the security considerations (cookies expire; API keys don't), my understanding is that auth cookies are a non-negotiable part of some customers' infrastructure due to proxying through servers unrelated to RStudio and Connect. This ticket has some more context: https://rstudioide.zendesk.com/agent/tickets/28560

@colearendt
Copy link

colearendt commented Aug 1, 2018

FWIW I like the idea of an arbitrary hook prior to deployment. I also like the idea of it not being .Rprofile, though, because there is no telling the types of weirdness you may run into there.

Perhaps unrelated, but I could also see potential value in a post-deployment hook, too. This would mostly be for UX stuff, I would think... committing the rsconnect folder or other workflow-y things.

@colearendt
Copy link

Another use case popped up for a pro customer today. They are running into issues having to unset / reset HTTP_PROXY in order to reach their Connect server. We are pointing them to fix the proxy itself, but having a pre/post hook in rsconnect would be another way to solve the issue from our end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants