Parameter encoding
-
This snippet adds a set of parameters to a URL.
URLEncoder.encode() replaces special characters with a %xx sequence, to get a valid URL.
The values of m_day, m_month, m_year are numeric. Since numbers are not special characters, this has no effect.
Also, the fixed string ORDERLEVEL is encoded. (No effect either.)
Then there are 2 fields containing a username and password (which might contain %, # and other things not allowed in a URL) are not encoded.
StringBuffer l_stringBuffer = new StringBuffer(p_data.getUrl());
l_stringBuffer.append("PSPID=" + p_data.getUsr() + "&");
l_stringBuffer.append("PSWD=" + p_data.getPwd()+ "&");
l_stringBuffer.append("level=" + URLEncoder.encode("ORDERLEVEL","UTF-8") + "&");
l_stringBuffer.append("ofd=" + URLEncoder.encode(m_day,"UTF-8") + "&");
l_stringBuffer.append("ofm=" + URLEncoder.encode(m_month,"UTF-8") + "&");
l_stringBuffer.append("ofy=" + URLEncoder.encode(m_year,"UTF-8") + "&");
l_stringBuffer.append("otd=" + URLEncoder.encode(m_day,"UTF-8") + "&");
l_stringBuffer.append("otm=" + URLEncoder.encode(m_month,"UTF-8") + "&");
l_stringBuffer.append("oty=" + URLEncoder.encode(m_year,"UTF-8") + "&");
l_stringBuffer.append("structure=" + "EXT" + "&");
l_stringBuffer.append("format=" + "xml" + "&");
l_stringBuffer.append("st4=" + "1" + "&");
l_stringBuffer.append("st6=" + "1");
-
The plain text password is another 2 WTFs, 1) that it exists in the first place, 2) that it is passed as a url parameter.
Also, hungarian notation to denote the scope of variables.
-
I'm sure the l_ is pure laziness, because the IDE usually generates declarations of the form "TypeName typeName = " automatically and then leaves the cursor in the identifier's name for you to update. But a password in a URL, I'm sure there are people that find that interesting.
-
@derari said:
The plain text password is another 2 WTFs, 1) that it exists in the first place, 2) that it is passed as a url parameter.
Also, hungarian notation to denote the scope of variables.
The prefixes belong to a coding style that was abandoned long before I joined the team. (I don't like them either, but changing them all takes too much time.)
It's actually a HTTPS request, so it shouldn't be visible.
-
@ggeens said:
It's actually a HTTPS request, so it shouldn't be visible.
Your manager told you this, right?
-
@ggeens said:
Except in the goddam server logs. Not a secure and responsible place to store people's personal data.@derari said:
The plain text password is another 2 WTFs, 1) that it exists in the first place, 2) that it is passed as a url parameter.
Also, hungarian notation to denote the scope of variables.
The prefixes belong to a coding style that was abandoned long before I joined the team. (I don't like them either, but changing them all takes too much time.)
It's actually a HTTPS request, so it shouldn't be visible.
-
Mini-WTF:
@ggeens said:URLEncoder.encode(m_year,"UTF-8")
URL percent-escapes are de-facto always UTF-8.
-
Why are you just not using a map/bag/whatever and automatically dealing with all the encoding somewhere else.
-
@MiffTheFox said:
URL percent-escapes are de-facto always UTF-8.
URL escapes encode 8-bit bytes. Now they are usually utf-8, but they used to be lot of various encodings few years back.
-
@Bulb said:
URL escapes encode 8-bit bytes. Now they are usually utf-8, but they used to be lot of various encodings few years back.
I remember that time. Encodings of escapes in URLs mostly followed the encoding of the page that they were embedded in. (Except for some browsers IIRC.) Bookmarks? Bwahahahaha!Sometimes technology definitely takes a turn for the better, and encodings are one of the places where this is unambiguously true.
-
I'm not sure which I like more...
The separation a single string literal into a complicated concatenation of string literals,
or doing that when you have a StringBuffer which you just don't use some of the time.
-
But I heard it's faster with a StringBuffer!