Oh Shit! Here we go again!

>> [ ]

if request_permissions:
//some if shit
raise 404

It was supposed to raise 404 for empty array, but continue to exit if.

Me: What the fuck?

**printing request POST data**
**empty, nothing wrong here**

**double checked print statement output**
** still printing [ ] **

**restart server and again checking print statement**
**still same**

Getting mad over myself, for failing to debug simple if else.


>> <class 'str'>
Me: What the actual fuck??

Fucker literally dumped empty array to JSON causing array to convert into string "[ ]" and still using if else based on array instead of string length.

Thanks to our Product Manager who approved our request to revamp this part of code and also revamping the whole shitty project developed by 3rd party in upcoming quarter.

  • 1
    Python? 🙄
  • 0
  • 1
    @scorpionk I know this is not what you'd like to hear....

    But assuming POST contains an array isn't right.

    You can dump everything into POST.

    Best example would be an ND JSON string (newline delimited JSON) for a bulk API endpoint.

    Sooo validate a bit more carefully ;)
  • 2
    def debug(input):
    print(type(input), input)
  • 0
    @IntrusionCM I'm always open to new suggestions by keeping ego aside.

    But I think you might have misunderstood my rant.

    POST data was array because it was HTML form old style submission. It is something django framework does for you.

    The variable mentioned in rant is later initialised as empty array and wasn't directly getting POST data but it was supposed to get json after processing.

    JSON dumping done after for loop operation to store JSON directly into Postgres database as JSONField.

    But apart from all this shit, thanks for suggestion about nd json.
  • 1

    Ah ... K.

    Many people expect POST to be an array because of HTTP multipart forms.

    I've seen many APIs who fail hard on that part, which is one of the reasons my first test against any new API is sending an body string and checking for nuclear fallout. XD
  • 2
    Well, the sender had to convert it to string because json doesn't really do arrays. If you expected it to be an array every time, then you should've converted it back first using numpy or some shit. I mean, print is not going to return an error because it got its favorite type.
  • 0
    @NoMad I think my English is the problem here.
    I know sender will send a json string. But as you can see my reply to @IntrusionCM.
    This part of code is not about accepting POST data.
    It is already accepted properly by request.POST.getlist() method which is Django framework's in built method to convert JSON string array to proper array of dict.

    My rant is about another variable which initialises empty array and receives values after processing of above array of dict.
    This variable is again converted to JSON string to store in database JSON field.
  • 2
    @scorpionk in your first response, you said it was supposed to get json after processing. Even after processing, json won't really touch the values because it could potentially corrupt them. So it waits for you to convert them.

    Also, getlist just gets a list of values for the mentioned key. It doesn't automatically convert.

    Your English is fine. I didn't really read your comments in detail.
  • 1
  • 2
    Also, in case numpy is not your thing, there are other/older methods, such as:

  • 2
    @scorpionk @NoMad

    I think I understood what ScorpionK meant. And stackoverflow.... Leave that toxic pile of garbage, it's useless.

    @scorpionk Good rant :)

    So to sum it up, the error was in parsing the value (which was extracted from POST).

    And someone initialized an variable holding the value with [] / list, but overwrote it with a string.

    Hence you assumed that the variable was a list, but fell flat - as it was a string representing an empty list.

  • 2
    Ahhhhhhh I finally see!!!!
  • 0
    That gives me some trolling ideas. Thanks!
  • 3
    @netikras If u meant feeding POST data which might not be "expected"...

    My top 4 is:
    1) empty string / string of control characters ( /r/n /t ...)
    2) invalid JSON or JSON containing values that are not supported in some languages (64 bit unsigned integer...)
    3) testing the limit by sending exponentially larger data... some APIs or better servers can be easily shutdown by sending large bulk data ... OOPS it OOMed again....
    4) Stress testing all 3 and waiting if the server / any server dies due to missing HD space (faulty error propagation, noone should try to write an 100MB string in a log)

    Till now the number of surviving API endpoints is quite low. Russian method for the win...
  • 0
  • 1
    @scorpionk Got ya back, buddy ;) :)
  • 1
    @IntrusionCM There's one more I do like: if it's a web API, sending just a value "undefined" as either text input :) Or as a blob for that matter...

    And reporting as "It's not working".

    Or even better -- wait until the recipient of that form reports it :)
  • 0
    @netikras good one...

    I'm really happy I am not working as a freelancer... I really hate most of the time the outcome of such tests and even more the lengthy discussions afterwards....... It's just **(*!€("(€!€("!€!€
  • 0
    @IntrusionCM I'd be careful about #3 and #4. This is no longer playful trolling - it could be classified as a legitimate DoS attack.

    Playful trolling is when people spend time trying to find a bug that never existed.

    Taking/slowing a service down is far beyond the line and makes you an offender
  • 1
    @netikras Yes. I think I'll write a short rant about it, as I've gotten bit curious.

    As I said, I'm not a free lancer.... And I would never run such tests against prod... For many many good reasons xD

    I'll do these tests usually when a new API endpoint is "born"... Just to get a valid first impression of it.

    When there is no dev ... I'll have an 64 GiB RAM playground server where I can do whatever the fuck I want to do. XD
  • 1
    this is why strict typing is a useful feature of useful languages
Add Comment