If I were you, I'd use an Integer Primary Key (auto ident) on your table and also add a GUID with a unique constraint & index on it, defaulted to UUID()

Sonra URL bir GUID almak ve masa aramak için kullanmak teçhizat sayfanız kadar.

Siz bilgi iki parça dışarı veriyoruz:

• kayıtları kolayca öngörülebilir url
• toplam sette kaç kayıtları bulmak kolay

Bunlar sizin uygulamanız için bir sorun vardır, o başka bir şey kullanmak

Sen Db anahtar için GUID adlı kullanabilirsiniz, ama bu büyük veri kümelerinde potansiyel performans etkileri olabilir.

URL bir kaydın id koymak genellikle bir sorun değildir. Örneğin, bu tarayıcı penceresinin URL bakmak ve bu sorunun id göreceksiniz.

Nedense kimliği açıkça görünür olmasını istemiyorsanız eğer değerini karıştırmak veya şifreleyebilirsiniz. Eğer izlendi olan bazı kayıtları korumak gerekiyorsa, bu tabii ki güvenli bir yöntem değildir, o zaman size oturum kimliği gibi kimlik çeşit ile birleştirmek zorunda kullanıcı oturum açmış.

Edit:
For proper security one has to focus on the real problem. If certain pages should have restricted access, the problem is not that anyone can figure out the URL to the page, the problem is that anyone can view the page. An URL can always be obtained some way or the other (e.g. package sniffing), so security has to be implemented in some other way.

Sen gerçekten yararlı bir yanıt için çok az bilgi vermek.

• Nasıl bir URL oluşturulur?
• Nasıl yazılım kayıtları görüntülemek için buluyor?

O dedi, ben böyle kimliklerini ortaya çıkarmak için sorunlu kabul ediyorum. Commmon çözüm geçici IDS kayıtları bir dizi için veritabanını sorgulamak her zaman oluşturmak ve içten tempID-> gerçek kimliğini saklamak için. Sonra URL içine bu geçici kimlikleri koymak ve sunucu üzerinde çevirmek.

Bu yaklaşım ile olası bir sorun birisi sırayla URL kimliği arttırılmasıyla tüm sayfalar / kayıtları almak için çok kolay olmasıdır. Ancak bu yine de güvenlik için karanlık URL'leri kullanarak güvenmemelisiniz, ne istediğinizi olmayabilir.

Diğer bazı seçenekler olacaktır:

• (Bu kötü bir anlamsız url olacak olsa da) her satırda bir rasgele karma oluşturmak
• Her satır için 'sümüklü böcek' (örneğin, 'kötü bir fikir-to-var-iki-unique-kimlikleri-in') oluşturun. Açıktır ki, örneğin, bu benzersiz olduğundan emin olmak gerekir Bunun için başka bir şey ekleyerek.

Belki böyle bir başlık yerine bir birincil anahtar olarak benzersiz bir tanımlayıcı, maruz gerekir? Lütfen PK açığa neccessarily bir güvenlik riski teşkil etmez, ancak başka bir niteliği açığa çıkarabilir eğer arama sonuçlarında daha yukarı alabilirsiniz.

Kullanıcı istek birincil anahtar kendisini savunmasız değildir. Sadece tamsayı değeri içine döküm ve hepsi bu

$id = (int)$id;.

Diğer bir soru erişimi bazı kayıtlar kısıtlayan ilgili. Bu sorun orada erişimi için bazı kurallar ekleyerek, sorgunun basit düzenleme ile çözebilir. Koşulu Eğer tip yönetici / editör / okuyucu / konuğu kullanıcıları varsa Örneğin SET alanına erişim hakları kurtarabilecek ve sorguya eklemek

SELECT ... 
FROM mytable 
WHERE 
    id = (int)$id 
    AND 
    (FIND_IN_SET('admin', access) OR FIND_IN_SET('editor', access))

...
if (!$fetch = mysql_fetch_acssoc($res))
    throw new Exception('Record not found or you have no permission to access it');

Yani, birincil anahtarlar için endişelenmenize yok - SQL-enjeksiyonları önlemek için tamsayı içine dökme unutma eğer oldukça güvenlidir.

O zaten söyleniyor (pratikte tablodaki her satır teşhir konum) ve ben bunun gerekli olduğunu sanmıyorum o kadar iyi bir fikir değil.

Kullanıcıların (bir liste veya ne olursa olsun bir öğe seçerek), belirli bir senaryo sonra bu sayfaya alacak düşünüyorum, bu nedenle (bir MVC mimarisini kullanmaya çalışıyorsanız) bir sayfa göndermek ve denetleyici olacak herhangi bir idare olacaktır işleme ihtiyaç ve sadece bir www.yoursite.com / displayElement.htm olabilecek bir görünüm sayfaya gönderir

Bu şekilde kimliği sadece bir oturum değişkeni olarak geçirilir ve her yerde gösterilmez.

Ama durumda ben yanlış anladım ve katalog çeşit görüntülerken, böylece tür, sadece kimliği dayalı karmaşık bir dize yaratacak bazı şaşırtmaca mekanizma eklemek gerekiyor daha, kullanıcılar imi sayfalara mümkün olmak istiyorum URL'ye göndermek ve gerçek kimliğini elde etmek için kod bunu çözme önce kimliğini kodlayan.

Bir kullanıcı zaten o sayfayı izleyebilirsiniz, ben kimliği kullanarak hiçbir sorun bakın. Onlar url değişen eğlenmek ve rastgele sayfalara gitmek istiyorsanız, ben hiçbir sorun olurdu.

Sayfaları herkes tarafından izlenmesi için değilse, ben aslında hala onunla hiçbir sorun olurdu. Bu durumda ise, onlar görmek için izin verilmez sayfaları görmesini önleyecek olan neyse bazı yetkilendirme onay olmalıdır neden olur.

Ne açıklayan konum Direk Nesne Referans olarak bilinen güvenlik açığıdır. Bunlar doğal olarak kötü değil, ama Insecure Direct Object References ve OWASP Top Ten içerisinde 4 vardır.

O zaman o görüntü yok etmezse, nesne geçerli kullanıcıya aittir işaretleyerek doğrudan nesne referanslarını güvenli olabilir.

Buna ek olarak, hatta bir erişim engellendi mesajı bilgi vermek olabilir. Lütfen parametre ise, örneğin, bir sipariş numarası, bir saldırganın bir 404 almak kadar basit sayısını artırarak onları görüntülemek bile şirket gerçekte kaç emir keşfetmek olabilir.

Şahsen ben sadece veritabanında birincil anahtar olarak dolaylı nesne referans biçimi olarak Guıd'ler kullanmak, ama besbelli değil.

Tehdit düzeyi kapsamı ve hedef kitleye bağlıdır:

1. Bu bir iç rezil uygulaması nedir? Eğer öyleyse, muhtemelen bu konuda endişelenmenize gerek yok.
2. (Twitter mesaj gibi) bu halka açık bir bilgi midir? Yine, muhtemelen bu konuda endişelenmenize gerek yok. Aslında, öngörülebilir URL muhtemelen bağlamak için idealdir.
3. Kimliği doğrulanmış kullanıcılar herhangi bir kaydı değiştirmek ya da zannediyorsunuz değil bir şey görebiliyor musun? Sen bir mülkiyet sistemi uygulayarak bu riski azaltabilir.
4. Bir 1 tıklama eylem veya XSS açığı neden olabilir? Eğer yapabilirseniz, sen yanlış yapıyorsun.

Genel olarak ben tahmin URL yanayım. Söyleniyor, onlar kullanılabilir ve bunları kimlerin görebilirsiniz nasıl düşünmek önemlidir.

Eğer insanlar sadece URL tahmin olmadığından emin olmak istiyorsanız, o zaman burada basit bir yaklaşımdır. Bu secure (yani kontrol erişimi için bu yöntemi kullanmayın) hiçbir şekilde, ama emin sadece giriş rastgele bir url olamaz ve bu sayfaya sendt olsun yapacaktır.

Url başka bilgi parçasına sahip kimliğini tamamlıyor. Ben id tuzlu bir karma öneririz.

Bir url oluşturulurken:

$id = 5;
$hash = md5($id . "MY_SALT_VALUE");
$url = "/$id/$hash";

Ve kaydını görüntülerken:

$params = explode(',', $_SERVER['REQUEST_URL']);
$id = $params[0];
$hash = $params[1];
if($hash != md5($id ."MY_SALT_VALUE")) {
    die('Uh oh! You guessed the URL, didn\'t you! Bad user!');
}
$data = $MyModel->load($id);
if(!$data) {
    die('No such record');
}
DisplayModel($data);

Tabii ki, bu (sadece die() ing yerine uygun bir 404 sayfa, ve benzeri ve benzeri, hata iletileri çok fazla söyleyerek) bir mockup.