Once we were going to present a web service to governmental firm. All is going well so far and my boss asks me to host the web application the day before the presentation.

I hosted it and all was good with demo production tests, but I had a bad feeling.

While it was running on our server, I also ran it locally with a reverse proxy just in case.

* Meeting starts *

* Ice broken and down to business *

"And now our developer will run the demo for you..."

* Run the demo from my laptop to double check --> 500 Internal Server Error *

Holy shit!!!

* Opens reverse proxy link on my laptop. Present demo during meeting. Demo works like a charm. *

Firm representative: "Great! Looking forward to go live."

*Our team walks out*

GM: "Good job guys"

ME:

Have multiple and some server related but hereby:

I forcefully quit php on the server I use for devRant related stuffs because I wanted to quit the bakgrounded php process I had running for the dns proxy thingy since I somehow couldn't find the pid.

Two days later I noticed that none of my sites on that server where running anymore and started looking at nginx error logs.

It took me way too long to figure out that I had PHP-FPM installed which runs as a service and by forcefully quitting php the other day.... Yeah, you get it I think.

Started the process again and remembered that one 😅

I've found and fixed any kind of "bad bug" I can think of over my career from allowing negative financial transfers to weird platform specific behaviour, here are a few of the more interesting ones that come to mind...

#1 - Most expensive lesson learned

Almost 10 years ago (while learning to code) I wrote a loyalty card system that ended up going national. Fast forward 2 years and by some miracle the system still worked and had services running on 500+ POS servers in large retail stores uploading thousands of transactions each second - due to this increased traffic to stay ahead of any trouble we decided to add a loadbalancer to our backend.

This was simply a matter of re-assigning the IP and would cause 10-15 minutes of downtime (for the first time ever), we made the switch and everything seemed perfect. Too perfect...

After 10 minutes every phone in the office started going beserk - calls where coming in about store servers irreparably crashing all over the country taking all the tills offline and forcing them to close doors midday. It was bad and we couldn't conceive how it could possibly be us or our software to blame.

Turns out we made the local service write any web service errors to a log file upon failure for debugging purposes before retrying - a perfectly sensible thing to do if I hadn't forgotten to check the size of or clear the log file. In about 15 minutes of downtime each stores error log proceeded to grow and consume every available byte of HD space before crashing windows.

#2 - Hardest to find

This was a true "Nessie" bug.. We had a single codebase powering a few hundred sites. Every now and then at some point the web server would spontaneously die and vommit a bunch of sql statements and sensitive data back to the user causing huge concern but I could never remotely replicate the behaviour - until 4 years later it happened to one of our support staff and I could pull out their network & session info.

Turns out years back when the server was first setup each domain was added as an individual "Site" on IIS but shared the same root directory and hence the same session path. It would have remained unnoticed if we had not grown but as our traffic increased ever so often 2 users of different sites would end up sharing a session id causing the server to promptly implode on itself.

#3 - Most elegant fix

Same bastard IIS server as #2. Codebase was the most unsecure unstable travesty I've ever worked with - sql injection vuns in EVERY URL, sql statements stored in COOKIES... this thing was irreparably fucked up but had to stay online until it could be replaced. Basically every other day it got hit by bots ended up sending bluepill spam or mining shitcoin and I would simply delete the instance and recreate it in a semi un-compromised state which was an acceptable solution for the business for uptime... until we we're DDOS'ed for 5 days straight.

My hands were tied and there was no way to mitigate it except for stopping individual sites as they came under attack and starting them after it subsided... (for some reason they seemed to be targeting by domain instead of ip). After 3 days of doing this manually I was given the go ahead to use any resources necessary to make it stop and especially since it was IIS6 I had no fucking clue where to start.

So I stuck to what I knew and deployed a $5 vm running an Nginx reverse proxy with heavy caching and rate limiting linked to a custom fail2ban plugin in in front of the insecure server. The attacks died instantly, the server sped up 10x and was never compromised by bots again (presumably since they got back a linux user agent). To this day I marvel at this miracle $5 fix.

Switched to DuckDuckGo, because Google thought it would be nice, to ban the Proxy IP of our company (because you know, many requests) from searching and putting us behind these captcha monstrosities. I don't want to captcha myself out of every query I have for goddamn 2 minutes with slow ass fading images.

Turns out, I like their service even more.

I have a Windows machine sitting behind the TV, hooked to two controllers, set up as basically a console for the big TV. It doesn't get a lot of use, and mostly just churns out folding@home work units lately. It's connected by ethernet via a wired connection, and it has a local static IP for the sake of simplicity.

In January, Windows Update started throwing a nonspecific error and failing. After a couple weeks I decided to look up the error, and all the recommendations I found online said to make sure several critical services were running. I did, but it appeared to make no difference.

Yesterday, I finally engaged MS support. Priyank remoted into my machine and attempted all the steps I had already tried. I just let him go, so he could get through his checklist and get to the resolution steps. Well, his checklist began and ended with those steps, and he started rather insistently telling me that I had to reinstall, and that he had to do it for me. I told him no thank you, "I know how to reinstall windows, and I'll do it when I'm ready."

In his investigation though, I did notice that he opened MS Edge and tried to load Bing to search for something. But Edge had no connection. No pages would load. I didn't take any special notice of it at the time though, because of the argument I was having with him about reinstalling. And it was no great loss to me that Edge wasn't working, because that was literally the first time it'd ever been launched on that computer.

We got off the phone and I gave him top marks in the CS survey that was sent, as it appeared there was nothing he could do. It wasn't until a couple hours later that I remembered the connectivity problem. I went back and checked again. Edge couldn't load anything. Firefox, the ping command, Steam, Vivaldi, parsec and RDP all worked fine. The Windows Store couldn't connect either. That was when it occurred to me that its was likely that Windows Update was just unable to reach the internet.

As I have no problem whatsoever with MS services being unable to call home, I began trying to set up an on-demand proxy for use when I want to update, and I noticed that when I fill out the proxy details in Internet Options, or in Windows 10's more windows10-ish UI for a system proxy, the "save" button didn't respond to clicks. So I looked that problem up, and saw that it depends on a service called WinHttpAutoProxySvc, which I found itself depends on something called IP Helper, which led me to the root cause of all my issues: IP Helper now depends on the DHCP Client service, which I have explicitly disabled on non-wifi Windows installs since the '90s.

Just to see, I re-enabled DHCP Client, and boom! Everything came back on. Edge, the MS Store, and Windows Update all worked. So I updated, went through a couple reboots-- because that's the name of the game with windows update --and had a fully updated machine.

It occurred to me then that this is probably how MS sends all its spy data too, and since the things I actually use work just fine, I disabled DHCP Client again. I figure that's easier than navigating an intentionally annoying menu tree of privacy options that changes and resets with every major update.

But holy shit, microsoft! How can you hinge the entire system's OS connectivity on something that not everybody uses?

!rant

I've seen some rants about people complaining about websites using the 'www' subdomain, so I'd like to take this opportunity to try to explain my opinion about why sites might use it.

I use to feel the same way about not having the www subdomain. It felt like an outdated standard that serves no purpose. But I have changed my option...

Sometimes certain servers have other services running other than just the website, such as ssh, ftp, sql, etc., running on different ports. What if you want to use a web proxy and caching service similar to cloudflare or a cdn? We'll you can't, because they won't allow traffic to flow through to your other ports.

That's where the www subdomain comes in. Enable your caching and cdn on your www subdomain, and slap a 301 redirect from your primary domain on port 80 or 443 to the www subdomain. This still allows you to access your other services via the domain name while still gaining the benefits of using a cdn.

Now I know you could use an 'ftp' subdomain or the like, but to each their own in that regard.

So for those of you keeping track, I've become a bit of a data munger of late, something that is both interesting and somewhat frustrating.

I work with a variety of enterprise data sources. Those of you who have done enterprise work will know what I mean. Forget lovely Web APIs with proper authentication and JSON fed by well-known open source libraries. No, I've got the output from an AS/400 to deal with (For the youngsters amongst you, AS/400 is a 1980s IBM mainframe-ish operating system that oriiganlly ran on 48-bit computers). I've got EDIFACT to deal with (for the youngsters amongst you: EDIFACT is the 1980s precursor to XML. It's all cryptic codes, + delimited fields and ' delimited lines) and I've got legacy databases to massage into newer formats, all for what is laughably called my "data warehouse".

But of course, the one system that actually gives me serious problems is the most modern one. It's web-based, on internal servers. It's got all the late-naughties buzzowrds in web development, such as AJAX and JQuery. And it now has a "Web Service" interface at the request of the bosses, that I have to use.

The programmers of this system have based it on that very well-known database: Intersystems Caché. This is an Object Database, and doesn't have an SQL driver by default, so I'm basically required to use this "Web Service".

Let's put aside the poor security. I basically pass a hard-coded human readable string as password in a password field in the GET parameters. This is a step up from no security, to be fair, though not much.

It's the fact that the thing lies. All the files it spits out start with that fateful string: '<?xml version="1.0" encoding="ISO-8859-1"?>' and it lies.

It's all UTF-8, which has made some of my parsers choke, when they're expecting latin-1.

But no, the real lie is the fact that IT IS NOT WELL-FORMED XML. Let alone Valid.

THERE IS NO ROOT ELEMENT!

So now, I have to waste my time writing a proxy for this "web service" that rewrites the XML encoding string on these files, and adds a root element, just so I can spit it at an XML parser. This means added infrastructure for my data munging, and more potential bugs introduced or points of failure.

Let's just say that the developers of this system don't really cope with people wanting to integrate with them. It's amazing that they manage to integrate with third parties at all...

I hate ADFS and SAML... that is all.

Since, I am already using Mullvad's vpn service, I also stumbled on https proxies.
Is it still safe to enter my devRant login data, when I would use a https proxy in FF's settings?
The Proxy is a free elite https proxy.
And devRant also uses SSL.
The traceroute would seem like this I guess.:
VPN(*le me sendin my password -> SSL Proxy -> SSL DevRant)
--------------------
Following that path, I would assume that it would be like this in detail:
HTTPS Request
-PW gets encrypted by VPN service
-" " " again " HTTPS Proxy
-" " " again " devRant itself

My client installed a new proxy that severely blocks out most of their own intranet, including their IT service desk. We can't raise tickets to let them know and their email just redirects us to their service desk. Fuck me these guys are idiots.

After waiting a while for another programmer on another team to provide a web service that I needed to call from a client side web form, I received word that it was ready. I could not get it to work because CORS headings were not being set correctly. After contacting them and letting them know, I got an email update to the team letting everyone know that they were waiting on me. After explaining that CORS headings were not there, I just built a PHP page to proxy the request, results and set the headers correctly so I can move on. I will remove it when they get their side fixed... if they ever do.

Probably the one where we had an error, because the service from a thirdparty we needed to install used a fourthparty service that was behind a proxy. Due of internal reasons we needed to use our own tomcat instead of the standard tomcat. We made a meeting because we didn't found out at that point that the problem was the firewall that dropped the packages from the application. We replayed it to them (at that point it was in my musclememory) and after a month i got the idea to use tcpdump to see if the server is calling another webservice, which was denied by the developers.

Spent days to setup a newer-Android version with reverse-proxy-HTTPS certificate in its CA store + one that'd support Google Play and signing in (old school man-in-the-middle).
FINALLY got the API calls of this 1 app whose unofficial client I wanted to make coz their main sucks ass. Just to get stuck on the phone-number-based OTP that they use for their login (:

They send a unique token for each OTP request, I assumed they're using some hard-coded string based function, which they decrypt on their backend to verify.
Downloaded their APK and decompiled. Went through dozens of weird-ass-named classes (coz decompiled). For the 2nd time I thought I had it!

But no -.- they call Google's Firebase messaging for the phone-num OTP n that function simply called firebase, looked into that service n ofc it's very tightly coupled with the calling API's backend

It was fun while it lasted I guess~~~

I'm in need of advice. I reckon this is no stack overflow but that's probably for the best as I wouldn't feel as comfortable posting there as I am doing it here. So, back to the question: I'm currently working with legacy code, written in .NET 2.0. This code is responsible for calling upon PEC services in order to finally create personal smart cards. I was tasked with the job of creating a repository system that would allow the program to call on the old legacy services or the new ones without any distinction. We are talking about SOAP services in both cases. The issues is: the new service definition is comprised of soap policies. This wouldn't be a problem per se, with more modern version of the framework, but with .NET 2.0? Yes, it is. It doesn't support policies and signing the body with a certificate right out of the box. How can I manage this? I feel like the only way would be letting the proxy class do its thing up until the very last moment: intercept the SOAP request before its sent and modify it according to the specifications. But I reckon this is very bad practice. Is there any other way out of this?

Thanks for anyone that would like to help. 🙂

Is there a cloud service that does nothing but redirect incoming HTTP requests to your home server without the need to have a static IP or an open TCP port ? Sort of like proxy

New ad self-service portal too hard to integrate ssl and can't have users send their passwords in plaintext.

Setup apache proxy with ssl in same vpc to encrypt traffic to and from vpc.

All good as long as nobody is in my vpc sniffing traffic...

From (Enterprise Service) bus to (proxy side)-car... we all grew up... ;-)