I noticed that the email confirmation links are using http:// vs. https://. Chrome has started to flag http:// links with a full-page speed bump, saying it is insecure. Perhaps those links should use https://?
I did try manually switching to https:// in the URL but Chrome didn't like the cert there either.
- The characters that enable the Host header field forgery aren't unicode characters. They are a subset of separator characters from ASCII. My guess is that the Akamai parser is trimming the Host header field name and not enforcing the requirements from https://www.rfc-editor.org/rfc/rfc7230#section-5.4 after this trim, specifically:
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
Even worse, the last Host header field appears to "win" and be the selected Host header field in the request forwarded to the origin.
- The OP does mention that Akamai intends to enable stricter header field parsing in 2023 but that response leaves a lot to be desired. They could probably provide a proactive analysis of a customer's traffic to inform them that they can turn on RFC compliant parsing without impact. Punting this decision to their customers requires their customers to be HTTP experts. If I were an Akamai customer, I would expect them to be my HTTP experts for me.
This is spot on. I'm very glad to see this post mention the "No Silver Bullet" essay. Despite being written in 1986, it continues to provide a relevant, skeptical view on the impact of these LMMs on software. It even has a section addressing whether AI can provide the "silver bullet", which is drawn upon by the OP.
My immediate response to all the rightly-deserved excitement for ChatGPT is to reread that essay and reflect on whether this new tool will provide me more than marginal gains in my productivity. Experimenting with it a bit over the last day, my initial answer is, no, this doesn't provide more than marginal gains outside toy examples.
These tools may very well factor into my workflow in the future, but I don't see them fundamentally changing the way I construct, support, debug, and maintain software.
I find myself returning to this blog post about once a year. It think it has aged pretty well in the decade since it was written.
One thing that definitely did not pan out is being able to understand the source of a website/web app because it is written in JavaScript. Transpiling/minification/etc. without the corresponding source maps makes that near impossible for any app of a reasonable size.
This post seems to suggest that a SaaS startup would consider creating their own SAML implementation. If a SaaS startup is considering creating a homebrew SAML implementation, they are doing it wrong.
When it comes to SSO, "buy" instead of "build", and focus on the core value proposition of the service with that saved time and resources.
Out of curiosity, which SSO service providers allow end-customer to self-configure the SAML integration? Essentially every service that I have seen the SAML integration is only configurable by the service provider and often there isn't even API that could be used to let SP expose the functionality.
This is actually something we’re working on at PropelAuth[0]. Our general philosophy is that most SP’s don’t want to deal SAML and would prefer to just have their users manage their own org membership - whether that’s via SAML, invitations, etc.
We haven’t built an API for it though, instead opting for a UI that walks the end-user through the steps of integrating with their IDP. That’s partially because every IDP is so different that we felt you really need a UI to show exactly what to do.
"Use OSS" is very close to if not the same as "Build".
To adopt an OSS approach for SSO, the startup still needs to dedicate resources to researching the OSS options, deploying the OSS, integrating it, and most importantly, operating it.
Once the startup gets into the weeds of integrating SSO functionality with customer's IdPs, in the limit, the cost of the effort will start to approach "Build".
The rust+wasm story is quite nice these days. I've been working on a rust+wasm SPA for a few months and I have yet to run into issues with the tooling (wasm-pack, wasm-bindgen, etc).
Fromy past experience working woth wasm-bindgen, it seems that you cannot get auto-completion for web APIs due to the fact that they are generated dynamically. Is this issue resolved now? What IDE/editor do you use to enable that?
Perhaps your comment was meant to be tongue in cheek, but it sounds like this data exchange is a replacement for the World Wide Web? It's not IPFS is it?
By the measure of the parent comment, and, I think globally. It's often best to accommodate an argument when you have more than one way to make your case. If someone believes that unemployment is on the rise, despite the facts that you (specifically) may have, let them win it - because they have seen the same facts and don't care.
Posts about the Web and the software that powers it. Light on content right now but will hopefully change that soon.