Состояние гонки при переходе прямо на защищенную страницу

Question

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

Код Iron-Router:

function secured() {
    if ( Meteor.user() == null ) {
        Meteor.loginWithLinkedin({
        },function (err){
            if(err){
                console.log("Error when login with LinkedIn."+JSON.stringify(err));
            }
        });
    }
}

Router.map(function () {this.route('customer_researchRequest', {
    before: secured,
    waitOn: waitOnHuman,
    path: '/research/request',
    template: 'customer_researchRequest',
    layoutTemplate: 'customer_requestLayout'
});});

На сервере:

    ServiceConfiguration.configurations.remove({
        service: 'linkedin'
    });

    ServiceConfiguration.configurations.insert({... settings ...});

Если пользователь переходит непосредственно к /research/request, возникает условие гонки.

1. перед условием пожаров
2. (на клиенте)ServiceConfiguration.configurations не имеет конфигурации
3. Клиент имеет исключение о том, что не определена служба сервиса.
4. сервер публикует ServiceConfiguration.configurations для клиента

На данный момент мое решение состоит в том, чтобы жестко закодировать в clientId и другую информацию конфигурации linkedin в код аутентификации linkedin ( Yech).

Есть ли лучшее, более элегантное / правильное решение?

Обновление № 1: Мое решение состояло в том, чтобы настроить пакет meteor-linkedin так, чтобы он ожидал в качестве опции идентификатор clientIn и не зависел от ServiceConfiguration.configuration. Таким образом, clientId всегда доступен.

Answer 1

Лучшим решением оказывается мой "взлом" создания разветвленного метеорного кода, который принимает конфигурацию клиента при входе в систему.

Мы отредактировали meteor-linkedin так, чтобы вызов Meteor.loginWithLinkedIn() предоставил идентификатор clientInd для связанного.

В настоящее время служебная конфигурация Meteor хранится в таблице монго и должна быть опубликована с сервера клиенту. ClientId - это по существу статическая переменная конфигурации, которая также может быть закодирована в клиентском коде. Простое добавление linkedin clientId непосредственно в код входа в систему оказывается намного надежнее и проще.

Даже если бы "Метеор" должен был "исправить" состояние гонки публикации, мы бы придерживались нашего решения: оно пуленепробиваемое и гарантированно работало. Вы можете позаимствовать наш код наш метеорит-linkedin и аккаунты-метеор-linkedin

Разработчики метеоритов не планируют исправлять проблему. Я согласен с этим решением: гораздо лучше иметь (постоянную) конфигурацию клиента на клиенте, чем хранить ее на сервере и отправлять клиенту.

Обновление: В конце концов, по разным причинам, мы почти полностью отказались от кода метеорной речи. Ориентированный на клиента подход с всплывающими диалогами вызвал множество проблем. Я говорю о некоторых проблемах в отчете об ошибках 1911 года. В итоге мы сами запустили код oauth на стороне сервера.

Answer 2

Отредактировано по адресу комментарий:

Может быть, другое использование реактивности может помочь. Установите отложенное перенаправление на customer_researchRequest, сначала отвлекая пользователя, а затем вызывая его

A) Secured() сохраняют исходный целевой путь к сеансу. Перейдите на страницу, которую вы разрешаете без защиты (или на страницу "Загрузка..."), чтобы избежать # 3
B) когда происходит обратный вызов входа в систему, сохраните другой флаг в сеансе, указывая, что #4 больше не соответствует действительности. C) перенаправьте Deps.autorun на нужный путь, когда оба флага станут истинными.

Кто-то может знать более умный способ (возможно, waitOn должен проверить конфигурацию), но...