sytringy05

Java applets were terrible in all possible ways that something can be terrible and it took no less than Steve Jobs to kill off Flash.

This stuff was foundational to the modern web and it's clear the maintainers, who probably are not Steve Jobs, have no idea what will break as a result. If it's removed, it will just get added back in after the outrage

I worked for an aircraft parts manufacturer, they closed an entire factory / production site rather than try and upgrade the manufacturing system or move the part production onto the new one they had implemented.

500 people out of work. Tell me again how simple everything is to fix.

The issue with myki wasn't the card technology, it was the fact they wanted to have standardised ticketing across the entire state.

eg Tap on a bus, tram and train in Melbourne, get off in Wangaratta and tap on to a bus there.

There was going to be something like 29 zones, and all the requirements / edge cases / mucking around sent the cost through the roof.

<7000 lines of cut / paste YAML later> “it’s that easy!”

It’s from the original borne / korn shell in Unix. Ctrl H was backspace, but the pc keyboards would send a different control character. you often had to map the backspace on the pc keyboard to make it work properly. Set -o or something like that.

Pretty interesting way to run what's in effect a XSS attack.

It's interesting to hear that because IHMO one of the reasons OAuth and JWT took over the world is that you can base64 decode the tokens and see whats inside them, compared to Kerb or NTLM which you eventually learn to spot based on their binary headers or whatever (eg NTLM tokens in HTTP Headers always start with "TRIM" for some reason)

I get the problem though, many of the libraries are not great or simply difficult to use

Well hopefully someone has taken the time to, or there will be nasty surprises

I certainly don't want people building security sensitive parts of an app to be slinging the features out.

The whole point of access tokens is to not do expensive checks on every request. Signature checks out and isn't expired - you are free to go. This is a core design thing of OAuth, once access tokens are out the door they are very hard to stop, so only let them last for 5 or 10 mins and use refresh tokens to get new access tokens.

Refresh tokens are your chance to do all the expensive checks - maybe you are IP restricted or want to step up with MFA etc etc. Check revocation etc

Yes, single log out is an ongoing nightmare. <Stares at Ping> As many here have said the size and range of use cases that OAuth and OIDC support is off its head. And that's with the big boys who have millions of users, throw in ${EveryCorp} that implements its own token server and bespoke implementation of the auth, well.. good luck to the AI trying to take over our jobs.

lol, here's my visual flow which consists of "start" -> "script node" -> "end"

Still, people buy Dell Boomi and Mulesoft, so it's not like there's no market for this rubbish

It wasn't a draft, it was reviewed, approved agreed upon etc, but the initial reason to do it was supporting a review of how things were integrated. Basically because it was useful and there wasn't anything else like it, they turned into the "how everything works" view.

because that's just how it was there... wasn't the best place in the world to work.

I once made the mistake of doing a set of rather detailed integration diagrams for an airline I was consulting at.

This diagram, which was intended to be a rough snapshot of how the systems interacted, instead became the single point of reference for how everything in the company worked. It was used to justify investment, knock back projects, one PM even tried to use it to dragoon AD into a PCI Compliance project due to a couple of lines on the aforementioned diagram (like this system has cards, line goes to Exchange as it alerts via email and AD is connected to Exchange. AD is now on the PCI hook).

It was the first thing I did there, leaving 4 years later. They were still in wide use 3 years after I left and hadn't being updated since they were drawn, not to mention they were flat out wrong in a number of significant ways to start with (either simplified for $REASONS or just didn't find out the real story until a year or 2 later).

These diagrams are probably the most impactful thing I've ever done in my career given how long they remained in daily use and the effort to draw them (which was probably a week or two? Took a long time to get the data but the drawing bit was pretty quick).

Would code have made them more accurate or likely to be updated? I doubt it. Would it have made them more useful? I don't think so, the key to them being well understood and useful was mostly in the layout, something that is difficult to control in any generated diagram.

I did actually have a go at using structurizr when I was there but it was too much work when compared to knocking out a quick draw.io.

Personally these days I make great use of PlantUML / WebSequence diagrams and am very interested in the C4 / mermaid stuff, but I would likely take the approach of the Engineering Manager - please produce diagrams and make them: 1 - accurate and 2 - useful for whatever story you are trying to tell.

Do it in code if you can make it work, but as someone in the thread said - this is an old problem and if it was easy it would have being solved in the 90s.

That said I've always thought a dependency system would be a good way to express the relationships between systems - you could almost model systems using something like maven poms - but again, it's always too hard to get the scope and resulting view right.

the main ones are OIDC plugin, the serverless plugin, advanced req and resp transformer plugins. auth connectors are useful, but most orgs I work with are using OIDC or SAML

does anyone know the history of the project? I hadn't really heard of this until earlier this year.

the same benefit you get from most reverse proxies. If you dont need it, then nothing. If you do need it, it's critical.

If you: - have more than 1 upstream service to hide behind your api.bigcorp.com name? - want to enforce standard authn/authz patterns across lots of teams/backend services? - want a standard approach to all the Quality of Service management? - want to have a well defined lifecycle for your APIs? - want to have a portal that describes the APIs, how they work and facilitate users getting access to them?

API Gateways are a thing because web servers that started out being used as reverse proxies were not that easy to configure and just did way too much web server stuff. API gateways made this easier, and added a host of security measures to make it somewhat safer when presenting APIs to the internet.

Then API management came along as a first class concern for orgs who want others to use their APIs.

It's good to see some FOSS innovation in this domain, most of the real open source API gateways are a huge mess. Kong is great, but the really useful stuff is part of the paid enterprise platform.

I think they were logging them in clear text, so server side, prolly ended up in splunk or elasticsearch.

This article answers its own question: "The situation is hopeless, but not serious."

REST vs HATEOS vs HTTP API vs Web Service

It's not serious and it doesn't matter that much. If I'm writing an API, I probably want to give people or systems access to my data and services. Missing links will be a mild inconvenience when compared to things like bad naming, inconsistent data structures, confusing error codes or domain complexity.

I wholeheartedly agree, which is why hardly anyone ever builds "REST" APIs. It doesn't really add that much to a data API

According to this web page - https://vicsig.net/infrastructure/signalbox/Metrol - it seems yes, it has been replaced.

> Train Describer replaced with TCMS in 2014-2016.

IIRC high speed signalling is coming with the Melbourne Metro trains (and the existing lines those trains will run through).

Replacing train management systems like this with new ones seems to be all but impossible, my brother in law worked on one in the UK that was designed, built and implemented and the controllers basically said "no thanks". It only got implemented when they rebuilt the UI and control panels to look like the old one.

No doubt, but there's always a way to smoke the whole thing, even with all the fail safe and redundancy in the world.

How about a shipping choke point and a city at the same time: https://xkcd.com/748/

Wow, I wonder if this will create some space for a new competitor? I mean apart from these 2, who else are a serious option for rock solid SaaS IdP?

Is remote from Melb possible?

The problem with TCP jokes is that people keep retelling them slower until you get them

If you dont have massive repos, then this is the sort of thing that not often a big problem. Also - if you are using things like gitlab runners, you might be in the same AZ and even large repos clones are fast.

And it is impossible to know it all, I like these articles just for the differing ways people work

I got an email from an Amazon recruiter through it.

GCP (Config Connector) and Azure (Service something) both have similar things. I've not heard of it happening outside a managed k8s env.