e js и express publi c и страницы просмотра частного маршрута - PullRequest
Новая
       5

e js и express publi c и страницы просмотра частного маршрута

0 голосов
/ 08 марта 2020

Недавно я создаю веб-сайт, используя express и e js, поэтому кроме express и e js у меня также будет один css и один javascript файл на внешнем интерфейсе, сайт, который я создаю, будет иметь панель мониторинга, которую пользователь должен будет сначала авторизовать, чтобы увидеть и использовать панель мониторинга, поэтому в целом на моем сайте будет несколько маршрутов publi c и два или три частных маршрута (с которыми пользователь должен войти, чтобы взаимодействовать).

У меня вопрос не с точки зрения производительности, а с точки зрения безопасности:

Для моего файла внешнего интерфейса javascript мне нужно разбить его на два файла так, один файл js предназначен для всех опубликованных страниц маршрутов c, а другой - для всех частных страниц маршрутов? если я просто использую один файл js на стороне клиента как для publi c, так и для частных страниц просмотра маршрутов, будут ли какие-либо проблемы с безопасностью? потому что, если я использую только один файл js на стороне клиента, я также буду использовать этот файл js для управления различными типами элементов DOM в частных маршрутах (например, dashboard.e js).

Пример:

Если у меня есть два publi c route, index.e js и about.e js, когда пользователь посещает эти publi c route сервер отправит publi c. js на клиентскую сторону, например: 

<body>
  <div class="container">
    <h1>index page</h1>
  <div>
  <script src="./public.js"></script> //This js file is used for all PUBLIC routes view pages
</body>

<body>
  <div class="container">
    <h1>about page</h1>
  <div>
  <script src="./public.js"></script> //This js file is used for all PUBLIC routes view pages
</body>

и после входа пользователя в систему и получения доступа к странице просмотра частного маршрута, например, к dashboard.e js, сервер будет отправлять личные данные. js на клиентскую сторону, например: 

<body>
  <div class="container">
    <h1>dashboard page</h1>
  <div>
  <script src="./private.js"></script> //This js file is used for all PRIVATE routes view pages
</body>

Есть ли необходимость использовать вышеуказанный способ, чтобы избежать каких-либо проблем безопасности, или я могу просто использовать один js файл на стороне клиента, чтобы позаботиться обо всех публикациях c и приватных маршрутах просмотра страниц DOM-манипуляции et c ...?

извините, если этот вопрос вроде ... Я все еще новичок в веб-разработке.

Спасибо

Ответы [ 2 ]

1 голос
/ 08 марта 2020

Прежде всего, безопасность данных достигается путем запроса соответствующих учетных данных для входящего http-запроса перед отправкой любых защищенных данных в ответ. Это не то, что достигается путем сокрытия клиентских файлов Javascript. Это достигается путем принудительной проверки учетных данных для любого http-запроса, который отправляет любые защищенные данные в HTTP-ответ.

Если ваш private. js просто выполняет манипуляции с DOM в браузере, то, возможно, даже нет быть какие-либо соображения безопасности, чтобы защитить его. Если сервер выполняет свою работу и отказывается отправлять какие-либо защищенные данные с соответствующими учетными данными, тогда ничего не может сделать только файл JS на стороне клиента, чтобы предоставить такие данные.

Если частный. js имеет некоторые Вещи, которые вы считаете секретами, тогда мы должны были бы по-настоящему понять, что это такое и каковы риски В большинстве (возможно, во всех) случаях эти «секреты», вероятно, следует перенести на сервер, где они также доступны или доступны только при наличии соответствующих учетных данных для авторизации. Код на сервере - это то место, где вы прячете «секретные» вещи, а не файлы JS на стороне клиента.

Для моего файла интерфейса javascript мне нужно разделить на два файла, так что один js файл предназначен для всех опубликованных c страниц маршрутов, а другой - для всех частных страниц маршрутов?

Это не должно быть связано с безопасностью. Ваши JS файлы не должны содержать важных секретов. Это должно быть больше о структуре кода и организации для эффективной работы (например, не посылать много кода на страницу, которая никогда не будет его использовать).

, если я просто использую один файл js на стороне клиента для как на публикуемых c, так и на частных маршрутах просмотра страниц будут ли какие-либо проблемы с безопасностью? потому что, если я использую только один файл js на стороне клиента, я также буду использовать этот файл js для управления различными типами элементов DOM в частных маршрутах (например, dashboard.e js).

Как упоминалось ранее, JS, который манипулирует элементами DOM, не должен рассматриваться как секретный код. Само по себе это не представляет угрозы безопасности. Данные должны быть защищены вашим сервером до того, как они попадут к клиенту.

0 голосов
/ 08 марта 2020

Так что я согласен с тем, что упомянул jfriend00, но я также добавлю свою перспективу.

Для моего файла внешнего интерфейса javascript мне нужно разделить на два файла, чтобы один файл js для всех страниц маршрутов c publi, а для всех страниц частных маршрутов? если я просто использую один файл js на стороне клиента для обеих страниц: publi c и частного просмотра маршрутов, будут ли какие-либо проблемы с безопасностью?

Как и другие комментарии, это не так. это действительно проблема безопасности. Если вы пишете интерфейс JS, единственное потенциальное нарушение безопасности - это включение ключей API, токенов, секретов и т. Д. c. Но это все равно идет вразрез с лучшими практиками. Таким образом, разделение файлов действительно сводится только к организационной структуре.

При этом, если у вас есть код JS, который имеет отношение только к вашим внутренним маршрутам и другим внутренним логам c, вы можете создать папку (которая не обслуживается клиент) для хранения внутренних JS файлов. Таким образом, ваш код упорядочен, и вы не станете выставлять логи c, которые вы можете или не можете sh скрыть. Примером этого может служить средство проверки формы для страницы входа в систему.

Это еще один вариант использования, который, как мне показалось, может оказаться полезным. Но я верю, что вы хотите достичь просто манипулировать элементами DOM, которые не должны представлять угрозу безопасности. Если вы думаете об этом, любой может изменить элементы DOM с помощью инструментов разработчика своего браузера. Но это не повредит вашим данным, серверной логике c или чему-либо еще на самом деле.

...