Как исправить ошибку подписи itsdangerous.BadTimeSignature

Я работаю над проектом (не над каким-либо совместным проектом, академическим). У меня проблемы с использованием его опасного и менеджера входа в систему из flask-login.

Я создал форму регистрации. ввел свое имя, адрес электронной почты и пароль, а затем, когда я перезапускаю сервер, я получаю это:

```
itsdangerous.BadTimeSignature
BadTimeSignature: Signature 'GAMjfzQpbKlPraWesdT49W40pA8' does not match
```

Поток ошибок такой:

return render_template('index.html')
  ctx.app.update_template_context(context)
    context.update(func())
 return dict(current_user=_get_user())
  current_app.login_manager._load_user()
    return self._load_from_cookie(request.cookies[cookie_name])
 user = self.token_callback(cookie)
line 93, in load_token
    data = login_serializer.loads(token, max_age=max_age)
.unsign(s, max_age, return_timestamp=True)
in unsign
    date_signed=timestamp)
BadTimeSignature: Signature 'GAMjfzQpbKlPraWesdT49W40pA8' does not match

Источник проблемы находится здесь, в основном файле запуска приложения:

line 93, in load_token
    data = login_serializer.loads(token, max_age=max_age)

@login_manager.token_loader
def load_token(token):
    max_age = app.config["REMEMBER_COOKIE_DURATION"].total_seconds()

    #decrypt token
    data = login_serializer.loads(token, max_age=max_age)

    user = find-and-get-user-object(data)
    if user:
        if data[2] == users password: return user object
    return None

app.config["REMEMBER_COOKIE_DURATION"] устанавливается как

app.config["REMEMBER_COOKIE_DURATION"] = some timedelta days

где дельта времени импортируется из DateTime.

Файл модели имеет пользовательскую модель, определенную в модели sql alchemy:

Base=declarative_base()

с помощью метода класса

get_auth_token(self):
        return login_serializer.dumps([str(self.id_), self.email, self.pwd])

Сериализатор входа основан на:

from itsdangerous import URLSafeTimedSerializer
app.secret_key = gen_random_key()
login_serializer = URLSafeTimedSerializer(app.secret_key)

Без диспетчера входа в систему маршрут отправки работал.

Я хочу знать, как работает строка функции load_token():

    data = login_serializer.loads(token, max_age=max_age)

влияет на токен, сгенерированный из модели пользователя, и почему он должен проверять совпадение на маршруте, скажем, «/» или любом маршруте, который может посетить любой случайный.

Нужно ли устанавливать ограничения разрешений, чтобы менеджер входа в систему не проверял каждый маршрут?

Альтернативный токен создается, как я понимаю, для более надежной привязки файлов cookie сеанса к файлам cookie на стороне сервера, поскольку информация о файлах cookie на стороне сервера будет сравниваться, что можно увидеть на основе get_auth_token, который принимает некоторые атрибуты пользователя и выдает случайную безопасную строку для токена.


person user2290820    schedule 09.05.2015    source источник
comment
Вы говорите, что создаете новый секрет приложения каждый раз при запуске сервера?   -  person Martijn Pieters    schedule 09.05.2015
comment
@MartijnPieters HoHoly дерьмо! так в чем проблема? Да я не экономлю! Я должен, вероятно, сохранить его в ENV сейчас!   -  person user2290820    schedule 09.05.2015
comment
@MartijnPieters спасибо за указание!   -  person user2290820    schedule 09.05.2015


Ответы (1)


Вы создаете новый секрет каждый раз здесь:

from itsdangerous import URLSafeTimedSerializer
app.secret_key = gen_random_key()
login_serializer = URLSafeTimedSerializer(app.secret_key)

Не делай этого. Создайте один секрет для своего приложения и постоянно используйте его. Ваши ключи подписываются с помощью этого секрета на стороне сервера, а затем, когда файл cookie отправляется обратно из браузера, снова используется для проверки того, что содержимое не было изменено.

Если вы каждый раз меняете секрет, ранее сгенерированные файлы cookie всегда будут недействительными, поскольку они не будут соответствовать новому секрету.

Сохраните секрет вместе с конфигурацией вашего приложения.

person Martijn Pieters    schedule 09.05.2015