Правильный способ программирования многопотоковых разговоров на переднем конце - PullRequest
0 голосов
/ 19 декабря 2011

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

Чтобы ответить потоку, идентификатор потока, который является просто идентификатором базы данных потока, находится в html, соответствующем потоку. Таким образом, javascript может получить идентификатор потока для потока, на который отвечают, и использовать его для передачи текста ответа и идентификатора потока на серверную часть через ajax. Он также используется, чтобы найти, где в HTML должен быть добавлен ответ.

Примером этого HTML будет:

<div id='thread_1' threadId='1'>Hey, how's it going?
  <div id='replies_1' threadId='1'>
  </div>
  <input id='reply_text_1' type='text' value='Reply...' threadId='1'></input>
  <input id='reply_button_1' type='submit' value='Reply' threadId='1'></input>
</div>
<div id='thread_2' threadId='2'>Anyone here?
  <div id='replies_2' threadId='2'>
    <div id='reply_2_1'>Yes, I'm here</div>
  </div>
  <input id='reply_text_2' type='text' value='Reply...' threadId='2'></input>
  <input id='reply_button_2' type='submit' value='Reply' threadId='2'></input>
</div>

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

К вашему сведению - в случае, если это поможет, серверная часть будет Java + Spring + Hibernate.

Любая помощь очень ценится!

1 Ответ

3 голосов
/ 19 декабря 2011

Наличие идентификаторов базы данных в html не является угрозой безопасности. На любом сайте вы часто будете видеть их в HTML и в URL. Важно то, что вы проверяете свои обратные вызовы, что текущий пользователь имеет доступ для удаления / чтения / ответа на сообщение.

...