@veggen said:
...not a single word understood o_O
Decoding what they type is half the fun of dealing with asian companies
@veggen said:
...not a single word understood o_O
Decoding what they type is half the fun of dealing with asian companies
From a customer who writes an application that interacts with ours:
"I debuged InputMethodManager.updateSelection to compare Email with other applications such as Memo and Message.
This issue happens even selectionStart and selectionEnd are the same to other applications.
Email uses updateInputMethodSelection() and updateInputMethodSelectionWithRandom().
- updateInputMethodSelection() sets curSelStart and curSelEnd as 0.
- updateInputMethodSelectionWithRandom() sets curSelStart and curSelEnd based on a random value due to webkit performance."
In other words, they decided to call us with 2 random numbers rather than reasonable defaults, then wonders why we aren't working right.
@makomk said:
@Javariel said:Its a bogus argument anyway- you don't send just the hash of the password. You use a system like this
Clinet: requests to login to the server
Server: responds with a random string
Client: hashes the password AND the random string
Server: does the same hash, checks that the two match. If so, it logs him in. If not, return an error
If another person tries a replay technique with the same hash, it
doesn't work, because the expected random value is not the same.
In a webpage, the initial request is basicly going to the login page
(its sent down in a hidden field). Such techniques are usually
not used with webpages though, since ssl is easy to use with a webpage.
For that matter, I don't think the server even needs to send down the
random string- the client can create it, and just tell the server
what was used. Saves a round trip.Actually, it's very important that the server (not the client) generates the random string - otherwise, someone could pull the hash and random string off the wire and replay them at a later date (this risk would be removed, or at least somewhat reduced, if the server kept a record of every random string used ever, but that's totally impractical).
@tofu said:
@masklinn said:I'd also have called dumb,
but for the reason that any user using a javascriptless browser, or
having javascript more or less disabled, would lose the ability to
access the website altogether.
And then I would call you
dumb for making such an assumption. Quite obviously, I would have
to make sure it worked when javascript was turned off. It is, in
fact, trivial to make something like this degrade gracefully. I
do it all the time. If you'd like example code just let me know.
Do
you not see the point of my question re: the fallacy of the
argument? If someone can sniff the line and get the hashed
password, then they can sniff the line and see the plaintext password -
and (here is the point) the plaintext password is more useful because,
for some users, it is the password they use for everything.
One big benefit. If your hashed password includes some random
data in the hash, you can then send the hash back in clear text without
using SSL, and yet be safe from replay hacks. This reduces server
load.
DD is mostly sold in the US. The official US format is mm/dd/yy. So June 8, 2004.
On #2
md5 is a 128 bit signature. So its 16 bytes, not 32. The
chance of generating the same string with 2 files is 1/2^16, or approx
1/65000. So the chance of 2 random files having the same md5 is
unlikely. Md5 does have some attacks though, so use of it for
cryptographic purposes is not recomended. Using it to id file
versions or the like is just fine.
If your original text is too short for the algorithm, you generally
fill the extra bits with a known pattern (all 0s) and take the md5 sum
of that.
I've seen plenty of do nothings in proprietary code. The main use
is to get rid of "Parameter was not used" warnings where the parameter
was added to maintain style- for example, a struct * (basicly a
this) pointer on a module where multiple instances are not supported.
The other is as previously described- as a fake to a function pointer where you don't want the null check.
Guru.com, by any chance?
The problem with those types of sites is the type of people who post projects
1/3 of them are looking for Indian contractors or Indian companies to do it on the cheap
1/3 of them are utterly unrealistic, expecting it to either be done in
1/10 the time needed and only willing to pay Burger King wages
1/6 of them are college kids looking to have their homework done for
them. They also can only pay BK wages, and if you remember
college- nothing was ever as easy as it should be.
1/6 of them are actually looking for rela contractors for fair
wages. Unfortunately, 2/3 of this group are a bit clueless and
can look like group 2, and these few have lots of bidder.