404362 - Changes to serving API

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Laura Thomson :laura]

Anything inside
https://addons.mozilla.org/api
probably shouldn't be availably publicly.

1.  We should serve this stuff via a different subdomain (api.addons.mozilla.org?) to avoid cross domain exploits.
2.  Even so, I'd like not to see it available outside of the VPN until it's ready for public consumption (anticipated December)

Comment 1

[Jeremy Orem [:oremj]]

If I set this up at api.addons.m.o do I need another instance of remora or can I just create a new vhost with /foo/api as the docroot?

Comment 2

[Laura Thomson :laura]

I can't see why a vhost wouldn't work.

Comment 3

[Reed Loden [:reed]]

Seems like there is a need for another wildcard SSL certificate for *.addons.mozilla.org now that we have both facebook.addons.mozilla.org and api.addons.mozilla.org.

Comment 4

[Jeremy Orem [:oremj]]

I think I'm a little unclear about the vhost.  Should it just be a mimic the current vhost so that the api is accessible at https://api.addons.mozilla.org/api or does it need to be accessible at https://api.addons.mozilla.org?

Comment 5

[Laura Thomson :laura]

That's a good question :)

I think the latter looks cleaner but I don't know how much it's going to confuse cake.

Comment 6

[Michael Morgan [:morgamic]]

Should probably go with api/ if we plan on using cake.  The alternative is using the latter and using a rewrite so we don't confuse cake.

Another alternative is to route things with api in the domain to the api controller... I think that's possible.

Comment 7

[Jeremy Orem [:oremj]]

What action should I take?

https://addons.mozilla.org/api <- is now forbidden.

Comment 8

[Michael Morgan [:morgamic]]

Let's go for the simpler api.addons.mozilla.org -- we should be able to make that work like we did with facebook, right?

Comment 9

[Jeremy Orem [:oremj]]

http://facebook.addons.mozilla.org isn't anything special.  I think all that logic is done through facebook itself.

Comment 10

[Michael Morgan [:morgamic]]

Damn, so for now let's set up api.addosn.mozilla.org/api and we will try to figure out if it's worth stripping /api off the end using routing magic or rewrites.

Comment 11

[Michael Morgan [:morgamic]]

Bleh, okay, so we talked about this and services.addons.mozilla.org/api seemed to be coolest -- Laura you ok w/ that?

Comment 12

[Jeremy Orem [:oremj]]

I have this set up at https://services.addons.mozilla.org/api/ looks like there is nothing to test yet, so we may have to reopen to iron out a few things once something is there.

Comment 13

[Laura Thomson :laura]

Hmm...should be there now, but the api urls give me 403s...can we open this up internally at least?  I know Mossop needs it for testing.

Comment 14

[Jeremy Orem [:oremj]]

I can either: 
* Open it up to everybody
* Put HTTP auth on it

Comment 15

[Dave Townsend [:mossop]]

Why wouldn't we open it up to everybody?

Comment 16

[Laura Thomson :laura]

We talked about this in the AMO meeting today.  It would be nice to have some kind of limited beta in place to begin with to iron out any wrinkles.  Basil was in favor of allowing access from a list of IPs if that's possible.  The goal is of course to open it to everybody after a short period.

Comment 17

[Dave Townsend [:mossop]]

Well if you need to restrict it to begine with then an IP access list is easier for me than authentication.

Comment 18

[Jeremy Orem [:oremj]]

Matthew, would you please create and internal VIP accessible via mpt-vpn?  Please reassign to me when you are done.

Comment 19

[matthew zeier [:mrz]]

oremj - this isn't any different than making any other vserver.  Only difference is you're picking an address out of 10.2.72 instead.

Comment 20

[Jeremy Orem [:oremj]]

It's looking like auth is going to be a lot easier with our current set up than making it vpn only.  Is using auth completely unacceptable?

Comment 21

[Dave Townsend [:mossop]]

(In reply to comment #20)
> It's looking like auth is going to be a lot easier with our current set up than
> making it vpn only.  Is using auth completely unacceptable?

Auth is actually preferable to me than VPN access, since I don't have VPN access to mpt.

Comment 22

[Jeremy Orem [:oremj]]

I realized this has been public for quite a while, maybe a couple months, at https://addons.mozilla.org/en-US/firefox/api/addon/7/

Is there any use in hiding it now? 

Comment 23

[Jeremy Orem [:oremj]]

What needs to be done to complete this bug?

Comment 24

[Michael Morgan [:morgamic]]

I think the only problem remaining is that the AMO URL should be disabled and the services URL is still broken:
https://services.addons.mozilla.org/en-US/firefox/api/addon/7/

We can disable the AMO URL via app config, but still unclear as to why the api is a 403 on the services vhost.

Comment 25

[Jeremy Orem [:oremj]]

(In reply to comment #24)
> I think the only problem remaining is that the AMO URL should be disabled and
> the services URL is still broken:
> https://services.addons.mozilla.org/en-US/firefox/api/addon/7/
> 

Anything with /api/ no longer 403s.

> We can disable the AMO URL via app config, but still unclear as to why the api
> is a 403 on the services vhost.
> 

Comment 26

[Dave Townsend [:mossop]]

Can I just clarify what the official URL for use should be. Comment 12 suggested it was https://services.addons.mozilla.org/api/ but that seems to redirect to https://addons.mozilla.org/en-US/firefox/api/...

Currently what appears to be working is:

https://services.addons.mozilla.org/%LOCALE%/%APP%/api/

Is that the correct url for me to hardcode into the app?

Comment 27

[Laura Thomson :laura]

Yes, that URL is correct.

Comment 28

[Jeremy Orem [:oremj]]

Can I close this or is there more to be done?

Comment 29

[Laura Thomson :laura]

Fine by me.  Dave?

Comment 30

[Dave Townsend [:mossop]]

Yep seems fine, I'll just file additional bugs if I hit any problems.