Hacker News Reader

Comment by efdee | Hacker News Reader

> That is, unless the enterprise has policies to abide by disallowing API calls

...What?

Welcome to enterprise, where breaking things is a feature so commonly used Microsoft has documentation for it [1] and things are often deployed by people whose sole concern is "minimize attack surfaces". Our Teams installation not only disables API calls (official Teams client only), chat sessions are deleted if no one posts to them meaning most chat history is lost every weekend.

[1] https://docs.microsoft.com/en-us/office365/troubleshoot/acce...

Microsoft uses these anti-features as a selling point, and in a large enough organization, it's not immediately clear who turned them on or who can turn them off.

What a perfect way to describe the situation.

Imagine an enterprise disallowing all VCS service providers -- whether hosted on-prem or cloud -- because they use SSH instead of HTTP.

You think you're joking but I've lived through exactly that. Reason: SSH cannot be examined by a HTTP proxy. The moment we raised that HTTP CONNECT is a TCP passthrough thus equivalent we got to install a bespoke root certificate on our machines for the proxy to MITM every single connection.

Yep. Sounds like a common-enough pattern then. (I wasn't joking in my post).

> Our Teams installation not only disables API calls (official Teams client only)

Wait? Can you even make API calls to Teams without getting the account owner to make a key for you? I’ve been looking for a way to use a personal key or credentials to make some calls, but the docs are absolutely impenetrable.

If the official client can still post and receive messages, what's preventing anyone else from doing it in the exact same way...?

Or is this something stupid like a user-agent check?

Reply on news.ycombinator.com