Uniquely identifying each & every html template

[Dennis Lee Bieber]

You are right, it cannot be done.

So i have 2 options .

Either identify an .html file from its "filepath" or from its "hash".

Which method do you advice me to utilize?

The hash identifies based upon the file contents -- any edit to the
file will result in a different hash (and if the hash system isn't large
enough, you may even encounter collisions where two or more files have
the same hash). However, moving or renaming the file should still
produce the same hash.

Path/name at least lets the file contents be edited. Anything that
changes the path/name will be seen as a new file.

Which condition is most useful to your needs: allowing free content
edits while keeping the counter tied to the end URL; or tying the
counter to a fixed page but letting the URL to that page change.

 

[Michael Torrie]

Τη ΔευτέÏα, 21 ΙανουαÏίου 2013 2:47:54 μ.μ. UTC+2, ο χÏήστης Joel
Goldstick έγÏαψε:

Just because you cannot answer my question that doesn't make me a
troll you know.

It becomes trolling when you refuse to even try to understand the
answers you are given. And you refuse to take the advise of many
knowledgeable people who have a lot more experience in web application
development than you do (I'm not including myself in this category).
You refuse to use a database in a way that it was designed to be used.
If you're unwilling to identify a file based on name, path, and
contents, then you're only solution is to use a database to associate a
particular file with an id. When you move or rename the file you have
to update the database. That's the only answer we can give you. Asking
the same question over and over again on different threads is not going
to change this. This is the third thread you've started on essentially
the same question. And you're getting the same advice on each thread.
There's a reason for this!

It's apparent that you don't have a lot of background in computer
programming or algorithms. That's okay. No one will fault you for
this. But if you're going to reject the solutions posed by those with
such background, then it behooves you to gain a bit of knowledge in
these areas and learn why these suggestions are going made.

I in no way intend anything I have said to be condescending. It's just
that those who are honestly trying to help you are getting frustrated.
And possibly you will interpret this frustration as hostility or
elitism, which it really is not.

 

[alex23]

My family in fact has a literal "grandfather's axe" (except that I
don't think either of my grandfathers actually owned it, but it's my
Dad's old axe) that has had many new handles and a couple of new
heads.

Ah, that's brilliant, I hadn't heard that term before, and it'll be a
lot easier to explain to people than the Theseus example.

How we think of identity is _awesome_

 

[Ferrous Cranus]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 1:55:07 Ï€.μ. UTC+2, ο χÏήστης Michael Torrie έγÏαψε:

You refuse to use a database in a way that it was designed to be used.

If you're unwilling to identify a file based on name, path, and

contents, then you're only solution is to use a database to associate a

particular file with an id. When you move or rename the file you have

to update the database. That's the only answer we can give you.

table counters: pin ---- page ----- hosts

table visitors: pin ---- host ---- hits ---- useros ---- browser ---- date

1. Who is going to create the 'pin' ? the database automatically when i'am inserting a new record from python?
2. How's the 'pin' going to be associated with 'page' ?
3. if 'page' renames/moves then i have to manually edit the counter database table to find the specific 'page' record and upadate it by hand?

I in no way intend anything I have said to be condescending. It's just

that those who are honestly trying to help you are getting frustrated.

And possibly you will interpret this frustration as hostility or

elitism, which it really is not.

They are getting frustrated because they do not want to follow the logic i'am imposing.

 

[Ferrous Cranus]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 1:55:07 Ï€.μ. UTC+2, ο χÏήστης Michael Torrie έγÏαψε:

You refuse to use a database in a way that it was designed to be used.

If you're unwilling to identify a file based on name, path, and

contents, then you're only solution is to use a database to associate a

particular file with an id. When you move or rename the file you have

to update the database. That's the only answer we can give you.

table counters: pin ---- page ----- hosts

table visitors: pin ---- host ---- hits ---- useros ---- browser ---- date

1. Who is going to create the 'pin' ? the database automatically when i'am inserting a new record from python?
2. How's the 'pin' going to be associated with 'page' ?
3. if 'page' renames/moves then i have to manually edit the counter database table to find the specific 'page' record and upadate it by hand?

I in no way intend anything I have said to be condescending. It's just

that those who are honestly trying to help you are getting frustrated.

And possibly you will interpret this frustration as hostility or

elitism, which it really is not.

They are getting frustrated because they do not want to follow the logic i'am imposing.

 

[Ferrous Cranus]

Τη ΤÏίτη, 22 ΙανουαÏίου 2013 11:08:57 μ.μ. UTC+2, ο χÏήστης Dennis Lee Bieber έγÏαψε:

On Mon, 21 Jan 2013 22:49:31 -0800 (PST), Ferrous Cranus

<[email protected]> declaimed the following in

gmane.comp.python.general:






The hash identifies based upon the file contents -- any edit to the

file will result in a different hash (and if the hash system isn't large

enough, you may even encounter collisions where two or more files have

the same hash). However, moving or renaming the file should still

produce the same hash.



Path/name at least lets the file contents be edited. Anything that

changes the path/name will be seen as a new file.



Which condition is most useful to your needs: allowing free content

edits while keeping the counter tied to the end URL; or tying the

counter to a fixed page but letting the URL to that page change.

The best would be to:

Allow free content edits, while the URL to that page may also change.

 

[Ferrous Cranus]

Τη ΤÏίτη, 22 ΙανουαÏίου 2013 11:08:57 μ.μ. UTC+2, ο χÏήστης Dennis Lee Bieber έγÏαψε:

On Mon, 21 Jan 2013 22:49:31 -0800 (PST), Ferrous Cranus

<[email protected]> declaimed the following in

gmane.comp.python.general:






The hash identifies based upon the file contents -- any edit to the

file will result in a different hash (and if the hash system isn't large

enough, you may even encounter collisions where two or more files have

the same hash). However, moving or renaming the file should still

produce the same hash.



Path/name at least lets the file contents be edited. Anything that

changes the path/name will be seen as a new file.



Which condition is most useful to your needs: allowing free content

edits while keeping the counter tied to the end URL; or tying the

counter to a fixed page but letting the URL to that page change.

The best would be to:

Allow free content edits, while the URL to that page may also change.

 

[alex23]

They are getting frustrated because they do not want to follow the logic i'am imposing.

No, it's because you're an obvious troll and you're wasting everyone's
time.

Now be a good lad and sod off.

 

[Mark Lawrence]

No, it's because you're an obvious troll and you're wasting everyone's
time.

Now be a good lad and sod off.

What an appalling lack of manners, it's sod off please

 

[Ferrous Cranus]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 11:37:29 Ï€.μ. UTC+2, ο χÏήστης alex23 έγÏαψε:

No, it's because you're an obvious troll and you're wasting everyone's

time.



Now be a good lad and sod off.

1. I'am a troll because i want to generate a solution in a specific way?
2. Am' i not wasting my time trying to reply to everybody?

 

[Joel Goldstick]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 11:37:29 Ï€.μ. UTC+2, ο χÏήστης alex23
έγÏαψε:

1. I'am a troll because i want to generate a solution in a specific way?
2. Am' i not wasting my time trying to reply to everybody?

This is so weird. Your time is not wasted, because your time is not
valuable. You aren't even a person. You are a fiction. If you were real,
someone would beat you to death, and you would stop annoying people. I
don't understand the troll thing. Its really anti social.

I like the web, but this is so strange

 

[Ferrous Cranus]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 2:03:51 μ.μ. UTC+2, ο χÏήστης Joel Goldstick έγÏαψε:

1. I'am a troll because i want to generate a solution in a specific way?

2. Am' i not wasting my time trying to reply to everybody?



This is so weird.   Your time is not wasted, because your time is not valuable.  You aren't even a person.  You are a fiction.  If you were real, someone would beat you to death, and you would stop annoying people.   I don't understand the troll thing.  Its really anti social.



I like the web, but this is so strange

--

http://mail.python.org/mailman/listinfo/python-list




--


Joel Goldstick
http://joelgoldstick.com

Who told you that my time is NOT valuable and yours is?
And yes iam an actual person.

 

[Ferrous Cranus]

Τη ΤετάÏτη, 23 ΙανουαÏίου 2013 2:03:51 μ.μ. UTC+2, ο χÏήστης Joel Goldstick έγÏαψε:

1. I'am a troll because i want to generate a solution in a specific way?

2. Am' i not wasting my time trying to reply to everybody?



This is so weird.   Your time is not wasted, because your time is not valuable.  You aren't even a person.  You are a fiction.  If you were real, someone would beat you to death, and you would stop annoying people.   I don't understand the troll thing.  Its really anti social.



I like the web, but this is so strange

--

http://mail.python.org/mailman/listinfo/python-list




--


Joel Goldstick
http://joelgoldstick.com

Who told you that my time is NOT valuable and yours is?
And yes iam an actual person.

 

[alex23]

1. I'am a troll because i want to generate a solution in a specific way?

No, it's because you have the name & behaviour of a known type of
troll:

As has been pointed out: http://redwing.hutman.net/~mreed/warriorshtm/ferouscranus.htm

"Ferrous Cranus is utterly impervious to reason, persuasion and new
ideas, and when engaged in battle he will not yield an inch in his
position regardless of its hopelessness. Though his thrusts are
decisively repulsed, his arguments crushed in every detail and his
defenses demolished beyond repair he will remount the same attack
again and again with only the slightest variation in tactics."

Sound familiar?

 

[Dennis Lee Bieber]

On Wed, 23 Jan 2013 01:12:31 -0800 (PST), Ferrous Cranus
<[email protected]> declaimed the following in
gmane.comp.python.general:

I shouldn't succumb to the continuation of these threads as they are
going past farcical to ludicrous.

table counters: pin ---- page ----- hosts

table visitors: pin ---- host ---- hits ---- useros ---- browser ---- date

1. Who is going to create the 'pin' ? the database automatically when i'am inserting a new record from python?

YES -- It's called a "primary key" and most all databases have the
ability to create one via an auto-incrementing field (that is, a new
number is generated whenever a new record is inserted that DOES NOT
SUPPLY the key field)

2. How's the 'pin' going to be associated with 'page' ?

The primary key is used as a foreign key reference in the other
table

3. if 'page' renames/moves then i have to manually edit the counter database table to find the specific 'page' record and upadate it by hand?

Well, you have that situation with ANY system in which you do not
have control over move/rename operation.

 

[Chris Angelico]

You think it's an accident that md5 size is roughly equivalent to 39 decimal
digits? Or that the ones that haven't been proven insecure are much larger
than that? The sha512 hash is roughly equivalent to 154 decimal digits.

Proving a hash function secure or not is orthogonal to its length. You
could have a cryptographically secure hash function that produces a
single byte; you'd get collisions pretty often, but that's understood.
Conversely, you could have an insecure hash that produces a value
several orders of magnitude longer than SHA512. Look at this:

def big_long_hash(val):
return sum(bytes(str(val),"utf-8"))*12345678901234567890

But longer hashes do reduce the chance of collisions, by the
fundamental rules of mathematics.

ChrisA

 

[Dave Angel]

Proving a hash function secure or not is orthogonal to its length. You
could have a cryptographically secure hash function that produces a
single byte; you'd get collisions pretty often, but that's understood.
Conversely, you could have an insecure hash that produces a value
several orders of magnitude longer than SHA512. Look at this:

def big_long_hash(val):
return sum(bytes(str(val),"utf-8"))*12345678901234567890

But longer hashes do reduce the chance of collisions, by the
fundamental rules of mathematics.

I certainly can't disagree that it's easy to produce a very long hash
that isn't at all secure. But I would disagree that longer hashes
*automatically* reduce chances of collision.

Anyway, about cryptographically ...

OK, I'd like to learn here. I thought that "cryptographically secure"
meant that it was infeasible to take a given message and make an
innocuous change to it (such as adding a trailer of whatever size) and
from that produce a predetermined hash value.

Obviously "infeasible" will change over time. But if my definition is
even close, then wouldn't it be a necessary (not sufficient) condition
that the hash be at least some certain size. It is that size I was
trying to impress on the OP.

Wikipedia - http://en.wikipedia.org/wiki/Cryptographic_hash_function

seems to say that there are four requirements.
it is easy to compute the hash value for any given message
it is infeasible to generate a message that has a given hash
it is infeasible to modify a message without changing the hash
it is infeasible to find two different messages with the same hash


Seems to me a small hash wouldn't be able to meet the last 3 conditions.

 

[Chris Angelico]

I certainly can't disagree that it's easy to produce a very long hash that
isn't at all secure. But I would disagree that longer hashes
*automatically* reduce chances of collision.

Sure. But by and large, longer hashes give you a better chance at
avoiding collisions.

Caveat: I am not a cryptography expert. My statements are based on my
own flawed understanding of what's going on. I use the stuff but I
don't invent it.

Wikipedia - http://en.wikipedia.org/wiki/Cryptographic_hash_function

seems to say that there are four requirements.
it is easy to compute the hash value for any given message
it is infeasible to generate a message that has a given hash
it is infeasible to modify a message without changing the hash
it is infeasible to find two different messages with the same hash

Seems to me a small hash wouldn't be able to meet the last 3 conditions.

True, but the definition of "small" is tricky. Of course the one-byte
hash I proposed isn't going to be difficult to break, since you can
just brute-force a bunch of message changes until you find one that
has the right hash.

But it's more about the cascade effect - that any given message has
equal probability of having any of the possible hashes. Make a random
change, get another random hash. So for a perfect one-byte hash, you
have exactly one chance in 256 of getting any particular hash.

By comparison, a simple/naive hash that just XORs together all the
byte values fails these checks. Even if you take the message 64 bytes
at a time (thus producing a 512-bit hash), you'll still be insecure,
because it's easy to predict what hash you'll get after making a
particular change.

This property of the hash doesn't change as worldwide computing power
improves. A hashing function might go from being "military-grade
security" to being "home-grade security" to being "two-foot fence
around your property", while still being impossible to predict without
brute-forcing. But when an algorithm is found that generates
collisions faster than the hash size indicates, it effectively reduces
the hash size to the collision rate - MD5 is 128-bit, but (if I
understand the Wikipedia note correctly) a known attack cuts that to
20.96 bits of "real hash size". So MD5 is still better than a perfect
16-bit hash, but not as good as a perfect 32-bit hash. (And on today's
hardware, that's not good enough.)

http://en.wikipedia.org/wiki/Collision_resistant

ChrisA

 

[Dave Angel]

Sure. But by and large, longer hashes give you a better chance at
avoiding collisions.

Caveat: I am not a cryptography expert. My statements are based on my
own flawed understanding of what's going on. I use the stuff but I
don't invent it.


True, but the definition of "small" is tricky. Of course the one-byte
hash I proposed isn't going to be difficult to break, since you can
just brute-force a bunch of message changes until you find one that
has the right hash.

But it's more about the cascade effect - that any given message has
equal probability of having any of the possible hashes. Make a random
change, get another random hash. So for a perfect one-byte hash, you
have exactly one chance in 256 of getting any particular hash.

By comparison, a simple/naive hash that just XORs together all the
byte values fails these checks. Even if you take the message 64 bytes
at a time (thus producing a 512-bit hash), you'll still be insecure,
because it's easy to predict what hash you'll get after making a
particular change.

This property of the hash doesn't change as worldwide computing power
improves. A hashing function might go from being "military-grade
security" to being "home-grade security" to being "two-foot fence
around your property", while still being impossible to predict without
brute-forcing. But when an algorithm is found that generates
collisions faster than the hash size indicates, it effectively reduces
the hash size to the collision rate - MD5 is 128-bit, but (if I
understand the Wikipedia note correctly) a known attack cuts that to
20.96 bits of "real hash size". So MD5 is still better than a perfect
16-bit hash, but not as good as a perfect 32-bit hash. (And on today's
hardware, that's not good enough.)

http://en.wikipedia.org/wiki/Collision_resistant

ChrisA

Thanks. I've read a lot about encryption and data compression (two
overlapping fields), and done some amateurish work (first time was 1975)
that was just to keep something secret, not to be especially secure. I
find the field fascinating, but have never needed to do anything
particularly secure for a real product.