Django: Conflito entre Live Sites & preparo no mesmo servidor

Question

Eu empurrei recentemente um aplicativo Django ao vivo. Nós construímos o aplicativo em um subdomínio de teste no servidor. Quando fui ao vivo, eu copiou os arquivos do subdomínio de teste para o site principal, criou um banco de dados de preparo e apontou o local de preparo de idade no novo banco de dados de preparo (deixando o novo site ao vivo apontou para o banco de dados original). Esta é em mod_python no Apache.

Eu criei configurações SESSION_COOKIE_NAME únicas para ambos os sites e tenho SESSION_COOKIE_DOMAIN conjunto com ".sitename.com" para o site ao vivo e Nenhum para o site de teste.

O problema que estamos vendo é que os usuários do administrador ao vivo estão fazendo edições que (parece) estão sendo salvas no site de teste. Os usuários também estão sendo registrados fora do local admin "aleatoriamente" durante solicitações.

Existe algo que eu estou claramente fazendo de errado aqui? Should SESSION_COOKIE_DOMAIN ser "www.sitename.com" para restringi-la desde o subdomínio está em "staging.sitename.com"? Será que eu deixar para trás antigas informações de sessão no banco de dados agora ao vivo (eu corri ./manage.py limpo e apagado todas as sessões do banco de dados ao vivo antes esta questão surgiu)?

Graças

Answer 1

Nós corri para este problema nas últimas semanas. Havia um par de lugares onde isso poderia se sobrepor.

1) Você está executando intérpretes python separados? Existem algumas maneiras para mod_python configure para que os fios não passo um no outro. Os pontos-chave aqui são para fornecer uma ServerName distinta (neste caso, os domínios staging.sitename.com e www.sitename.com ), bem como fornecer uma distinta configuração PythonInterpreter no seu arquivo de configuração do Apache vhosts.

PythonInterpreter mysite

docs Django relevantes no mesmo servidor implementações

2) Você está executando um backend de cache na mesma porta? Há uma configuração no settings.py que permite prefixar o conteúdo em cache com vários personagens para conteúdos de teste separado do conteúdo ao vivo. Isso é implementado com a seguinte configuração no settings.py:

CACHE_MIDDLEWARE_KEY_PREFIX = "STG_"

Outra opção poderia ser executado em caches de sistemas de arquivos separados por algum tempo para ver se o problema é resolvido. Em settings.py, tente adicionar

CACHE_BACKEND = 'file:///var/tmp/django_cache'

3) Você já tentou apagar todos os arquivos .pyc? Estranhamente, quando os dois acima soluções não conseguiu resolver o nosso problema, nós corremos um comando bash para apagar todos os arquivos python compilados (arquivos .pyc) enquanto o servidor foi parado.

find ./ -type f -name "*.pyc" -exec rm -f {} \;

Isto indicaria que as mudanças na sua implantação não foram recompilar por uma razão ou outra.

Espero que isso ajude!