1075044 - Allow developers access to staging server

Status: RESOLVED WONTFIX

(Webmaker Graveyard :: Login, defect)

Description

[inactivate account for kate]

What do you all think about:

- allowing certain localhost ports to access CORS
- giving out (committing) a secret key for local dev

for login.mofostaging.net?

This would greatly simplify the development process for any apps that rely on the login server (events, profile, wm.org, mobile webmaker, etc.)

Comment 1

[Simon Wex :wex]

+1 the idea, -1 for login.mofostaging.net.

I could see someone down the road chucking prod data onto mofostaging to test a solution and not considering the PII exposure through these dev keys. I'd be super down for having a test instance up that was specifically for devs that would be lower risk for this.

JP, I don't mind if the solution is what I'm suggesting above. Do you have an idea to make sure my fear would never materialize?

Comment 2

[inactivate account for kate]

Yeah good point. I think having another test instance in isolation running is totally fine as long as it's automatically kept in sync with staging and we minimize the amount of manual maintenance it will need (e.g. migrating dbs)

Comment 3

[JP Schneider :jp]

Yeah, this sounds like a good slot for a stable test env.    

What would you think about this:
1) We write a bit of automation to populate the login db with known user creds (user01/password10) type of thing.  
2) We host up the database and instance on the mozilla-labs dev account, keeping it even a little more separated from real envs.
3) We can call it login.mofodev.net (or flower, if you want) :)
4) We can even hook it up to puppet to ensure it stays updated with all the config changes from staging/prod but none of the access.

Comment 4

[Simon Wex :wex]

1) The new version of login doesn't use passwords, instead it relies on email. I don't think standard fixtures would really help for login specifically.
2) We shouldn't use the Labs account, that's being handed off to them and from a billing perspective we shouldn't have any costs there.
3) Something sensible and standardizable makes sense here
4) That'd be good as long as it doesn't mean we add the risk of exposure of real system credentials, I can't confidently say we don't have code that does this with "admin" access.

Comment 5

[inactivate account for kate]

I set up subdomains pointing to heroku instances at

login-dev.mofodev.net
makedrive.mofodev.net

for now. Let's make sure we have these automatically deployed and on SSL in the future

We could continue to use heroku if we add a deploy step, i.e. https://github.com/mozilla/login.webmaker.org/pull/298/files

Comment 6

[Pomax]

is this ticket still active?

Comment 7

[JP Schneider :jp]

I'm thinking this is all setup via the mofodev bits, but I'll defer to k88hudson.