Постараться не представлять первичные ключи в источнике веб-приложения?
If Cell.Value = UCase(base_Position) And UCase(reverse__BaseDirection) Then
Приведенный выше синтаксис неверен, но вы не предоставили достаточно информации, чтобы предложить решение, только предложения.
'If the text in base_Position equals Cell.Value and the text in reverse__BaseDirection equals Cell.Value
'this is unlikely because Cell.Value probably shouldn't be equal to both
If Cell.Value = UCase(base_Position) And Cell.Value = UCase(reverse__BaseDirection) Then
'If the text in base_Position equals Cell.Value and the text in reverse__BaseDirection equals Cell.Offest(0, 1).Value
'this is likely because Cell.Value equal one and the cell next to it equals the other
If Cell.Value = UCase(base_Position) And Cell.Offset(0, 1).Value = reverse__BaseDirection Then
Из вашего изображения не видно, что вам нужно UCase reverse__BaseDirection.
В любом случае вы можете видеть, как синтаксис And обрабатывает более одного сравнения.
Вы также должны установить searchCol_AB для объекта диапазона.
Set searchCol_AB = wsSyn.Range("A3:B100")
Если второе решение верное с использованием Cell.Offest (0, 1). Значение, вам нужно только просмотреть столбец A. Смещение будет смотреть на столбец B.
Set searchCol_AB = wsSyn.Range("A3:A100")
Завершите все это примерно так (см. Комментарии).
Option Explicit
Sub basePositionPairs()
'these only need to be strings, not range objects
Dim base_Position As String, reverse__BaseDirection As String
'you need to specify each one or they end up as default variants
Dim searchCol_AB As Range, rangeUnion_Copy As Range, rangeUnion_Paste As Range
Dim Cell As Range
Dim wsSyn As Worksheet
Set wsSyn = Worksheets("Syn_Calc")
base_Position = UCase(wsSyn.Range("K3").Value)
reverse__BaseDirection = wsSyn.Range("L4").Value
'look through column A and Offset to look at column B
searchCol_AB = wsSyn.Range("A3:A100")
'these full columns will be used with Intersect later
Set rangeUnion_Copy = wsSyn.Range("D:F")
'Start the paste at K9 (only top-left is required)
Set rangeUnion_Paste = wsSyn.Range("K9")
For Each Cell In searchCol_AB
If Cell.Value = base_Position And Cell.Offset(0, 1).Value = reverse__BaseDirection Then
'copy the intersection of the full columns and Cell's row
Intersect(Cell.EntireRow, rangeUnion_Copy).Copy _
Destination:=rangeUnion_Paste
'second copy from N3:P3
wsSyn.Range("N3:P3").Copy _
Destination:=rangeUnion_Paste.Offset(0, 4)
'advance rangeUnion_Paste down one row
Set rangeUnion_Paste = rangeUnion_Paste.Offset(1, 0)
End If
Next
End Sub
6 ответов
I disagree with the stance that exposing primary keys is a problem. It can be a problem if you make them visible to users because them they are given meaning outside the system, which is usually what you're trying to avoid.
However to use IDs as the value for combo box list items? Go for it I say. What's the point in doing a translation to and from some intermediate value? You may not have a unique key to use. Such a translation introduces more potential for bugs.
Just don't neglect security.
If say you present the user with 6 items (ID 1 to 6), never assume you'll only get those values back from the user. Someone could try and breach security by sending back ID 7 so you still have to verify that what you get back is allowed.
But avoiding that entirely? No way. No need.
As a comment on another answer says, look at the URL here. That includes what no doubt is the primary key for the question in the SO database. It's entirely fine to expose keys for technical uses.
Also, if you do use some surrogate value instead, that's not necessarily more secure.
Первичный ключ - это не то же самое, что суррогатный ключ или внутренний ключ, хотя есть некоторые совпадения. Противоположностью внутреннего ключа является естественный ключ. Много раз, когда естественный ключ используется в качестве первичного ключа. Как правило, нет причин скрывать естественный ключ, если только мы не занимаемся вопросами конфиденциальности.
Ваш настоящий вопрос, я думаю, о том, должны ли внутренние ключи открываться пользователям. Ответ: «Это зависит». Для большинства сообществ пользователей раскрытие внутреннего ключа приведет к тому, что ключ будет использоваться в качестве естественного ключа. Это может и обычно приводит к некоторой путанице, когда однозначное сопоставление между внутренним ключом и предметом строки таблицы нарушается.
Этот сбой может произойти только в результате неправильного управления данными. Однако большую часть времени Вы должны планировать некоторые ошибки в данных, происходящие в реальном мире. Вы не планируете систему водоснабжения, которая выходит из строя при неправильном управлении водой. Вы не планируете информационную систему, которая выходит из строя каждый раз, когда происходит неправильное управление данными.
Сказав это, большинство разработчиков баз данных в настоящее время работают на поставщиков программного обеспечения и не видят проблем, вызванных неправильным использованием данных пользователями их товары.
Не вижу проблем, вызванных неправильным использованием данных пользователями своих продуктов. Не вижу проблем, вызванных неправильным использованием данных пользователями своих продуктов.Yes, exposing keys is information that can be used as an attack. Especially if they are predictable.
Use a different key/column if you think the information is sensitive.
For example to avoid showing how may users you have, consider:
site.com/user/123 vs site.com/user/username
Yes to all your questions. I agree with your assertions that you should "expose some other value to the web app that can be translated back to the primary key"
You can open yourself up to potential problems otherwise.
Edit
Regarding the comment that "there is no reason to take the penalty hit for trivial keys. Look in your browser's URL right now, I bet you see a key!".
I understand what you're saying and, yes, I do see the key in the SO URL and agree it probably does refer to a database PK. I concede in instances like this it's probably OK if there's not a better alternative.
I'd still prefer to expose something other than a PK - something with semantic value. The title of the question is also in the URL, but since this would be hard to verify as unique (or pass between users verbally) it can't be used reliably on it's own.
When looking at the "tag" URLs however (i.e. https://stackoverflow.com/questions/tagged/java+j2ee), the PKs are not exposed and the tag names are used instead. Personally, I prefer that approach and would strive for that.
I also wanted to add that the data a PK points at can sometimes change with time. I've worked on a system where a table was filled with info from an offline process - i.e. monthly statistics where the DB table contents dropped at the end of the month and was repopulated with new data.
If the data is added to the db in a different order, the PKs for specific data points would change, and any saved bookmarks from a previous month to that data would now point at a different set of data.
This is one instance where exposing a PK would "break" an app unrelated to the security of the app. Not so with a generated key.
Как всегда, «это зависит». Если кто-то может получить прибыль (скажем), зная, сколько транзакций вы выполняете за (час / день / месяц), и вы представляете идентификатор транзакции как монотонно увеличивающееся число, то это риск.
Как и другие Тем не менее, для выпадающего списка значений, как правило, нет проблем.
Предоставление значений, отличных от первичного ключа, не избавит вас от бремени проверки вашей безопасности. Действительно, если в вашей безопасности есть дыры, «злые» пользователи могут по-прежнему получать доступ к объектам, для которых они не предназначены, изменяя значение в URL. У них может быть меньше подсказок, какие значения использовать, но при случайном выборе значений им может повезти.
Если вы хотите улучшить безопасность таким образом, вам придется использовать большие случайные строки (чтобы затруднить угадывание) в URL вместо идентификатора и использовать таблицу косвенного обращения, совпадающую со случайным значением с хорошим идентификатором на заднем плане. ,
Я думаю, что это не стоит хлопот большую часть времени.
Тем не менее, это полезно в тех случаях, когда вы хотите «безопасность из-за неясности», например, когда вы открываете страницы для изменения паролей пользователей, не требующий входа в систему (для пользователей, потерявших свой пароль). В этом случае вам также следует связать дату действия лимита с вашим ключом.