2013-04-06 14 views
9

Używam kompresora django na Heroku z Amazonem s3 obsługującym pliki statyczne i ciągle napotykam następujący błąd z wygenerowanymi przez kompresor linkami do plików statycznych. Jestem całkowicie nowym kompresorem i s3:django-compressor, heroku, s3: Prośba straciła ważność

https://xxx.s3.amazonaws.com/static/CACHE/css/989a3bfc8147.css?Signature=tBJBLUAWoA2xjGlFOIu8r3SPI5k%3D&Expires=1365267213&AWSAccessKeyId=AKIAJCWU6JPFNTTJ77IQ 

<Error> 
<Code>AccessDenied</Code> 
<Message>Request has expired</Message> 
<RequestId>FE4625EF498A9588</RequestId> 
<Expires>2013-04-06T16:53:33Z</Expires> 
<HostId>Fbjlk4eigroefpAsW0a533NOHgfQBG+WFRTJ392v2k2/zuG8RraifYIppLyTueFu</HostId> 
<ServerTime>2013-04-06T17:04:41Z</ServerTime> 
</Error> 

Mam skonfigurowane dwa serwery heroku, jeden do przemieszczania i drugi do produkcji. Każda z nich ma własną bazę danych i s3. Mają także ten sam plik ustawień, wszystkie unikalne ustawienia są skonfigurowane jako zmienne środowiskowe. Sprawdziłem, czy pliki statyczne są rzeczywiście przekazywane do ich odpowiednich segmentów.

kompresor & s3 są następujące ustawienia:

COMPRESS_ENABLED = True 
COMPRESS_STORAGE = STATICFILES_STORAGE 
COMPRESS_URL = STATIC_URL 
COMPRESS_ROOT = STATIC_ROOT 
COMPRESS_OFFLINE = False 

AWS_ACCESS_KEY_ID = os.environ.get('AWS_ACCESS_KEY_ID') 
AWS_SECRET_ACCESS_KEY = os.environ.get('AWS_SECRET_ACCESS_KEY') 
AWS_STORAGE_BUCKET_NAME = os.environ.get('AWS_STORAGE_BUCKET_NAME') 

każdym razem naciskać aktualizację Heroku na postoju lub produkcji, w końcu uruchomić w powyższej kwestii. Czasami zdarza się to po godzinie, czasami na dzień, czasem na tydzień, a czasem zaraz po wypuszczeniu aktualizacji. Dziwne jest to, że jeśli popchnę tę samą aktualizację do obu środowisk, jeden zadziała, a ja otrzymam błąd na drugim lub obie będą działać na początku, a jedna wygaśnie za godzinę, a druga wygaśnie za tydzień .

Byłbym bardzo wdzięczny, gdyby ktoś mógł wyjaśnić, co się dzieje. Oczywiście przyczyną problemu jest parametr Expires, ale dlaczego czas trwania zmienia się przy każdym naciśnięciu i co decyduje o czasie? W JAKI SPOSÓB MOŻNA ZMIENIĆ CZAS TERMINU? Daj mi znać, jeśli potrzebujesz więcej informacji.

AKTUALIZACJA: Tymczasowo rozwiązałem problem, ustawiając AWS_QUERYSTRING_AUTH = False. Wydaje się, że nie ma żadnego sposobu na ustawienie CZASU EXPIRATION w łańcuchu zapytania, a jedynie użycie w nagłówku żądania.

+0

Sprawdź, czy czas systemu serwera jest aktualizowany - Otrzymałem ten błąd podczas uruchamiania maszyny wirtualnej, w której nie synchronizowano czasu systemowego. –

+0

Jestem na Heroku i nie mam kontroli nad czasem systemowym. – arctelix

Odpowiedz

17

spróbuj tego:

AWS_QUERYSTRING_EXPIRE = 63115200 

wartości będący liczbę sekund od momentu, gdy linki są generowane.

+1

To zadziałało, ale czy możesz powiedzieć nam więcej o tym, dlaczego. Czy to jest ustawienie kompresora Botto lub django? Czy jest to udokumentowane w dowolnym miejscu? – arctelix

+1

To ustawienie boto i domyślnie boto umieszcza zapytania o wygaśnięciu na wyjściu adresu URL, ale są one raczej krótkie. Wydłuża to wydarzenie do dwóch lat. Znalazłem go tylko po przejściu przez źródło i zobaczeniu kilku odniesień do niego w międzyczasie. – mjacksonw

3

wszelki wypadek ktoś ma ten sam problem:

AWS_QUERYSTRING_AUTH = False 

ta usuwa wszelkie wygaśnięcia itp Wygaśnięcie nie zawsze jest potrzebne na podstawie przypadków użycia (jak w kopalni i wielu innych). Pozwoli to usunąć wszelkie wygaśnięcia.

+0

Właściwy sposób na zmianę czasu wygaśnięcia jest taki, jak opisano w odpowiedzi Wilkinsona. AWS_QUERYSTRING_AUTH = False wyłącza perłę epiracji, która była znana jako workroundround dla krótkiego czasu wygaśnięcia. – arctelix