Localhost only endpoint

Несмотря на рекомендации не изменять Object.prototype, это может быть действительно полезно для тестирования в ограниченном объеме. Автор принятого ответа изменил его, но все еще устанавливает Object.id, что для меня не имеет смысла. Вот фрагмент, который выполняет задание:

// Generates a unique, read-only id for an object.
// The _uid is generated for the object the first time it's accessed.

(function() {
  var id = 0;
  Object.defineProperty(Object.prototype, '_uid', {
    // The prototype getter sets up a property on the instance. Because
    // the new instance-prop masks this one, we know this will only ever
    // be called at most once for any given object.
    get: function () {
      Object.defineProperty(this, '_uid', {
        value: id++,
        writable: false,
        enumerable: false,
      });
      return this._uid;
    },
    enumerable: false,
  });
})();

function assert(p) { if (!p) throw Error('Not!'); }
var obj = {};
assert(obj._uid == 0);
assert({}._uid == 1);
assert([]._uid == 2);
assert(obj._uid == 0);  // still
2
задан Joelty 18 January 2019 в 13:51
поделиться

2 ответа

Как правило, нет. Тем не менее, я не думаю, что это лучший план в любом случае. Когда вы выдвигаете что-то публичное, вы должны предполагать, что все публично. Если есть что-то, к чему никто не хочет получить доступ, то auth - ваш ответ. Это также дает вам больше гибкости для того, что стоит. Все, что необходимо для локального взаимодействия с этим API, не всегда может находиться на одном сервере. Если вы используете auth, вы можете переместить его куда угодно без проблем. В противном случае он застрянет на одном и том же сервере, независимо от того, будет ли это иметь смысл в долгосрочной перспективе или нет.

Ваша следующая лучшая альтернатива - выделить функциональность и разместить внутри себя только внутренние компоненты. Попытка заставить один API обслуживать как внутренние, так и внешние запросы только добавляет ненужных усложнений.

0
ответ дан Chris Pratt 18 January 2019 в 13:51
поделиться

Есть несколько возможностей:

  • Пометьте его с помощью прагмы #DEBUG - так что это будет только в режиме отладки
  • Переопределение ExecuteAsync и проверка на наличие флага функции (см. Условно отключите контроллер ASP.NET MVC )
  • Заблокируйте его на балансировщике нагрузки перед вашим приложением (многие базовые приложения dotnet размещаются самостоятельно и получают доступ через локальный хост. Например, служба приложений Azure )
  • Использовать пользовательскую аутентификацию
  • Использовать флаг функции (например, переменную среды config entry) и проверить его внутри заблокированного контроллера
  • Использовать флаг функции (как выше) и пользовательская политика с такой проверкой (подробнее: https://docs.microsoft.com/en-gb/aspnet/core/security/authorization/policies?view=aspnetcore-2.2 )
  • [1110 ]
0
ответ дан Piotr Stapp 18 January 2019 в 13:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: