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.


  • Trolleybus Mechanic

    @ggeens said:

     It's actually a HTTPS request, so it shouldn't be visible.
     

    Your manager told you this, right?



  • @ggeens said:

    @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.

    Except in the goddam server logs.  Not a secure and responsible place to store people's personal data.




  • 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.


  • Discourse touched me in a no-no place

    @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!


Log in to reply