2013-03-13 7 views
8

Czy możliwe jest całkowite wyłączenie api explorera lub ograniczenie dostępu do niego?Uczyń api odkrywcę prywatnym

Zauważyłem niektóre dzienniki w mojej aplikacji pochodzące z nieudanych próśb wykonanych z przeglądarki. Moje api jest zużywane tylko przez aplikację na Androida, więc jedynym miejscem, z którego mogą pochodzić, jest api explorer. Również dostęp do interfejsu API jest ograniczony do 1 sieci i 1 identyfikatora klienta Android.

Odpowiedz

4

Niestety nie. Eksplorator interfejsu API działa przy użyciu usługi wykrywania powiązanej z interfejsem API, która w rzeczywistości nie jest częścią zaplecza, więc nie można określić uwierzytelniania lub widoczności tych identyfikatorów URI.

list metoda z serwisu Discovery służy do generowania listy po aplikacji APIs Explorer za pomocą aplikacji jako podstawy:

discovery.apis.list:

your-app-id.appspot.com/_ah/api/discovery/v1/apis

Kiedy ktoś klika jeden z interfejsów API z listy, pełny dokument wykrywania jest pobierany dla tego apiName i apiVersion przy użyciu metody getRest z usługi Discovery:

discovery.apis.getRest:

your-app-id.appspot.com/_ah/api/discovery/v1/apis/{apiName}/{apiVersion}/rest

+0

Czy masz jakieś zalecenia dla danej strony administratora wniosku? Widzę coś takiego jak/_ah/spi/{nazwa klasy usługi}. {Method} .. Czy można dodać wiele programów obsługi pasujących do /_ah/spi/.*? – 12345

+1

Zalecam, aby zaimplementować część Admin w metodach obsługi. 'endpoints.api_server' ma na celu stworzenie jednego programu obsługi dla wszystkich twoich API. – bossylobster

+1

Ale w jaki sposób uniemożliwić komuś usunięcie całej mojej bazy danych (Datastore)? – InsaurraldeAP

0

punkty końcowe sprawia auth łatwe i można uzyskać bieżącego użytkownika. Powinieneś użyć auth, aby zapewnić, że ludzie nie będą zadzierzgać twoich prywatnych api - w przeciwnym razie ludzie mogliby wyśledzić, jaki rodzaj postu lub otrzymasz prośby, które wysyłasz w każdym razie - auth jest zawsze dobrym pomysłem, a nie próbą utrzymania sekretu API w tajemnicy.

Jeśli tworzysz tajny produkt i nie chcesz, aby konkurent odkrył, możesz użyć metody zaciemniania na zapleczu i na kliencie, co powoduje, że apis jest nieczytelny.

Użytkownik, który włamał się do twojego apisa, nie powinien włamać się do twojej bazy danych - lub jeśli to zrobi - powinien ją złamać tylko dla użytkownika, który był głupi. Posiadanie logiki w twoim kliencie, jak używać api, aby backend nie został przerwany, jest złym pomysłem - backend apis powinien zadbać o siebie i nie martwić się o to, jak i dlaczego są używane i dla kogo w jakim celu.

+0

Widziałem, jak to ludzie mówią, ale czy możesz wskazać przykład, w którym punkty końcowe na GAE wymagają uwierzytelnienia bez konta Google (ale tylko identyfikator klienta określony w konsoli programisty)? Na przykład w moim przypadku mam interfejs API, którego używam z JavaScript, ale nie chcę, aby inni korzystali z moich interfejsów API. Na przykład jeden z moich interfejsów API zwraca odpowiedzi z ankiety podanej w tokenie. Nie chcę, aby dowolna osoba korzystająca z interfejsu API zrzuciła wszystkie odpowiedzi na ankiety, ale anonimowy użytkownik na stronie powinien mieć możliwość wyświetlenia odpowiedzi na ankietę z ich tokena. – SimplicityGuy

+0

Interesujący punkt - Czy możesz sprawić, by tokeny były nieczytelne? Byłoby miło móc ograniczyć dostęp api do programistów związanych z projektem w chmurze. (a także przyznać dostęp do niektórych domen). Być może będzie to jednak zbyt wiele funkcji dla punktów końcowych - łatwiejsze będzie zawijanie punktów końcowych w IMO zaplecza. –

+0

Tak, tokeny są nie do zniesienia (solone, oparte na czasie i wyjątkowe). Spędziłem ostatnią godzinę, próbując po prostu użyć identyfikatora klienta, a jednocześnie mogę uniemożliwić dostęp do interfejsu API, ale nie mogę uniknąć strony logowania Google ... Ale chcę tylko zalogować się zasadniczo jest identyfikatorem klienta, ponieważ ma już ograniczenia miejsca, z którego można wywoływać interfejs API. – SimplicityGuy

Powiązane problemy