Disclaimer: I haven't built this yet (primarily because it's too hard today).
I want to build self-hostable servers, to give our customers the option of privacy and easier compliance.
In that arrangement, there'd be:
- Our main / central server, for regular SaaS customers. It also provides public assets ("knowledge bases" in this case, but it could be anything - even just licensing info) that all signed-in users have access to. This would be the iDP.
- Many self-hosted clones of our central server, per customer
Because the central server has the most up-to-date shareable assets, which might be ahead of any upgrade schedule a self-hosted customer has, they'd want their signed in employees to have transparent access to those latest ones too. I.e. without the extra friction of additional sign-in.
tl;dr the ability to offer our customers an easy self-hosted option of our Supabase platform (with limited federated access to central data) is highly desirable, now that even SMEs request better infosec. Doing it all inside a Supabase Docker - rather than mixing in Okta - is what makes it maintainable and easy to share.
--- EDIT ---
This use-case could be written more simply:
- There's a platform/app server (built on Supabase). Customers can optionally self-host it for their business.
- There's a data server (also built on Supabase, but not self-hosted), that provides shareable assets, even to self-hosted servers.
My goal is that it's _seamless_ for self-hosted users to access the data server.
So the data server would need to be an iDP.
My preference for Supabase to do this (instead of Okta), is because offering a self-hosting option is currently an intimidating maintenance burden, so fewer moving parts (no Okta) is desirable.
I'm struggling to understand your use case here, but here are some thoughts that may be helpful.
You can use one Supabase Auth project to do all of your user management. You can use the JWTs issued by this project across any other system. You need to configure those systems to "trust" those JWTs, usually by sharing the signing key (JWT secret) with them. They can then base their allow / deny decisions on the JWT.
You can even do this with as many Supabase projects you want. You don't have to use Supabase Auth with all of them. Do note that once you use physically different machines, you need to sync them up and that's quite a big can of worms.
I can't advocate Supabase enough. Their combo of openness and elegance in their platform leaves me (a developer/entrepreneur) feeling secure.
This is perhaps a future topic, but to me it extends out of SSO:
Paul (@kiwicopple), do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase?
I suspect it's Cerbos or Casbin, but if you ever do it in house (and since you've nailed AuthN that makes great sense), my wishlist:
- It should be as simple as an API end point, .approve(auth.jwt(), Array<Role | Permission>). I.e. be available in Edge Functions, Postgres Functions, and anywhere else.
- Use a policy schema with the most industry support for easier acceptance/integration with the enterprise.
- Flesh out with enterprise-ready policy auditing tools, logging, etc. This is the real time saving for developers.
> do you have an opinion on which enterprise-grade AuthZ provider works best with Supabase?
Since you asked for my personal opinion, then I would say Postgres Row Level Security for AuthZ. RLS is as powerful as it is flexible. It's fully-integrated with the rest of the Supabase stack, and it's portable if you don't like supabase - just pg_dump and take it to your favourite Postgres provider.
That said, I understand why it's useful to have something more structured like RBAC. We have experimented with a ideas here (specifically ABAC), using a custom libraries/extensions/custom claims[0]. We do something similar internally, but aren't 100% happy with the developer experience and don't plan to release it any time soon.
I'm sure the Auth team won't enjoy me saying this, but I like the idea of Zanzibar. I've seen some experimental Postgres extensions[1] that combine Oso[2] + RLS which I'd love to try when I get time.
Supabase Logs will be fully-integrated with the rest of the supabase stack. Since the Auth JWT flows through the HTTP Authorization header, into PostgREST, then into Postgres, we can pluck the Supabase User ID out of the JWT and store it alongside every log entry. You will be able to reference/join every authorized action in your database to an authenticated user.
> RLS can't control access to API end points in places like Edge Functions (again, afaik).
also correct, for now. We released the Edge Runtime[0] this week, and plan to use it as a scriptable Proxy.
> In my experience, RLS has quite a few foot guns in it as schemas migrate
A very fair point. We hope that we'll be able to provide some tooling here.
Thanks for all of this feedback - it's incredibly useful. Our team read the HN comments thoroughly and it shapes our ideas for the product going forward. We have some gaps to fill for your requirements, but we'll get there.
Some additional feedback: In my opinion testing RLS is a problem.
Additionally, I find it hard to keep a good overview over the rules. E.g., in a multi-tenant application one needs to secure every table with a restrictive rule, and it's easy to make a rule permissive, since that is the default & it's not indicated in the Studio UI.
When generating migrations with 'supabase db diff' views are being recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before, leaving your database exposed. Easy to miss, even when you're aware of that.
RLS is just so full of footguns that I find it hard to justify using it in a production system.
we have a lot of work to do for migrations and testing, especially RLS.
for this Launch Week we focused on generating policies (more on that in tomorrows launch week). This is hard for a lot of our audience who aren't familiar with SQL.
In the next few months we'll work on simulating a policy - being able to choose a specific user and see what data would be returned for that user.
We also have `supabase test db`, in case you missed it. It wraps pgTAP and pgProve so that you can write database tests.
> recreated without 'WITH (security_invoker)' even though they had security_invoker turned on before
we use migra for diff'ing. Thanks for raising this - we'll file a bug report asap.
Replacing Kong with Deno is a great step (and by simplifying the stack, in line with the elegance I love Supabase for).
- My request with Supabase Logs is that they're easy to format in ways auditors expect (i.e. similar to major tools). That would be a headline benefit, because:
[1] As your customer, I have an easier time with SOC2
[2] In turn, I can pitch that to our enterprise customers: "your compliance will be easier, as your policy and log audits with us will match your other vendors"
I'm going to shoot this to your support channel, but a little more tiny feedback:
- There's no local way for a webhook Edge Function to flag "--no-verify-jwt", which means my local test environment can't be consistent with staging.
- I'm having to use Edge Functions for webhooks despite Postgres Functions being more desirable, because either Kong or PostgREST always requires a JWT. I'm guessing the switch to Deno will make this solvable.
If you use Supabase CLI to serve functions locally, you can use the `--no-verify-jwt` flag, ie. `supabase functions serve --no-verify-jwt` will skip JWT checks locally.
Is that what you're after? if you have any further issues with serving functions locally, can follow up on the support ticket.
If you need the flexibility of a system that can model both RBAC and ABAC and you also want you want a Zanzibar-inspired design, SpiceDB[0] is the only option that I know checks all the boxes (disclosure: I'm a maintainer).
The UX definitely isn't optimized for Supabase, but I'd love to learn more about how that could be improved. I suspect it might be complicated if Supabase assumes RLS for everything.
While SpiceDB looks good. My only concern is if they will go the mongo route once they get more adoption and need to satisfy investors as opposed to customers/developers and make most of their features paid and leave the open source version hanging.
Well, you're in luck because AuthZed, the business behind SpiceDB, has a fantastic track record in this regard. We're quite conservative with fundraising and the first year of the company was bootstrapped by the founders. The founding team also has a strong history of properly balancing open source businesses from their experience in leadership roles over the past decade at CoreOS and Red Hat.
Glad to chat with anyone privately if they want more details.
My Gmail plugin is coming from the same pain (I subscribed to a ton of great newsletters, but they clutter everything human): https://www.getbreef.com . It's just my side project, and it's in beta - let me know if you'd like to try it.
It gives desktop Gmail an RSS-esque topic view of your inbox, and lets you infinite scroll through emails like you would Twitter or Insta.
Turning Gmail into an infinite scroll like Twitter/Instagram. And grouping newsletters into topics to feel more like a RSS reader - https://www.getbreef.com
I start 99% of my emails with 'sorry' - I live in fear of going into my inbox, and so when I do it's a distinctly whiffy guilt laden experience, so I don't go in again for a while, and the cycle... well, you get the idea :-)
I've tried other addons to help (both using and making), but keep failing to invest the effort. In the end I went with "what's the simplest, speediest change that might have a lasting impact" and this was it.
It started as a weekend hobby in September, but I've been trying to polish it as more people have found it helpful. (This is hard work as I'm a dreadful aesthetic designer. It's more a case of 'monkey see, monkey copy the html').
We make an downloadable product [1] that over its lifetime has been sold as donationware, freemium and trial-based -- three of the main variants that shareware evolved into.
Short answer: downloadable trial software is still viable... we're doubling revenue each year and supporting a team of 6.
Donationware (product is free for life, occasionally nagged for money). Lesson's learned: 1) It's no way to live, but a good way to start, as the userbase was at it's most vocal with feedback back then, when we were trying to hit product/market fit (perhaps because 'donation ware' felt much more community-spirited). 2) I don't have exact conversion numbers, but I do remember being surprised by how much an individual donated ($1 was the minimum, $30 the average, $300 the max). I've read studies since that if someone is asked to name their own price, they'll be much more generous (the downside being not as many people will pay anything at all).
We then tried freemium (features were restricted until people paid). Lesson's learnt: 1) Do freemium by resource constraints, not feature constraints (i.e. all features are available, but when you use X amount of data you have to pay). Because otherwise users just see a 'broken' product, and don't see the point in paying for something less-useful. 2) We also noticed that most people quit in the first two weeks, and almost everyone who didn't, paid. I.e. the 'free plan' was hardly used (related to the first point). Thus it was just a maintenance burden.
Now we have a two week trial, and then you pay. Lesson's learnt: 1) Benchmarked against freemium, conversion increased 4% in real terms (and 20% in relative terms). Mostly because it nudged the small % of 'free plan' folks from above into buying.
If house prices cross a threshold where first time buyers can't afford to get onto the property ladder, they're forced to rent - driving up competition for stock & thus rental prices. (This appears to be affecting more & more people in the UK).
These people pulling the ladder up behind them might be in for a rude surprise.
A sketch of my argument: as we are sometimes reminded to bear in mind, prices are driven by market conditions and affordability, not costs. If prices shoot up, why will the rent increase? Is it not already set to the highest value the market can bear, or something very close to that? We'll assume it must be, because it would be silly to do anything else (and the tenancy market is liquid enough). But then, if prices are at the right level already, how will people pay for increased rent?
If salaries increase as well, then this is just ordinary inflation. House prices go up, rents have go up, salaries go up - well, people have been warning about this for years! On the other hand, if prices increase, and rents go up, and salaries don't, how are people going to be able to afford to pay for any of this? The obvious answer, of course, is that they won't.
Prices are what the market will bear. If everybody's costs go up, or supply is limited, then rent can sure go up. Renting is an inflexible demand - unless you want to go homeless.
As I understand, from one of the early Gmail product managers, element class names are the most stable of all the 'fingerprints'. The Javascript data structures are quite stable, and the element IDs change pretty much every session.
(Source: I'm the author of the ActiveInbox Gmail extension, and at various times have spoken to Gmail engineers directly).
I agree a service would be a useful thing. A killer bit of value would be if it could workaround Mozilla's addon rules. (We actually stopped publishing on Mozilla addons, because if Gmail changed, we couldn't wait 10 days to be "re-approved" to fix it, and as mentioned by gkoberger, Mozilla really clamps down on dynamic in-app updates).
Ymmv, but if it helps...
From the POV of an extension developer, service reliability is critical, and I'm not sure if there's enough GMail extension developers to be customers and make it economically viable?
If there is, I think the ideal service would taint DOM elements with class names to make the important things selectable (rather than a Javascript API to retrieve elements). That way, we could build our own selectors with fail safes to fall back on (and we don't have the security headache of incorporating your dynamically-updated code within our own protected sandbox. We can just share the modified DOM instead).
Whatever you do with it, I'm really impressed with how cleanly you built this kartikt!
Maybe it could just be a JSON file with the xpath of all important elements?
Also maybe it doesn't really have to be a service. It could just be a file on github, where anyone could issue a pull request if gets broken broken. That way way you would essentially crowd source it.
This space of "handle tasks in email" is starting to explode since pg called it as a giant opportunity. Indeed, I believe Mail Pilot are launching their public beta soon - the timing makes me think these guys were (savvily, tbf) trying to jump in alongside it.
It's not just another "todo list", it's really dealing with the pain of remembering the promises you make in email, and the fact email is used to discuss all the work we do, but is completely disconnected from our other management tools.
It's also obviously a positive thing that lots of innovative new products are getting involved: a single pioneer does not a movement make.
Disclaimer:
I've been working on ActiveInbox for Gmail[1], first as a hobby project and later as a bootstrapped business, since 2006. In fact I think we were the earliest, certainly for Gmail.
Oddly enough the transition from hobby to business came about in a very Kickstarter way, but long before it existed -- early users simply wanted to give money to keep us going, we refused at first because it was a "hassle to deal with tax" (this is also long before Lean Startup: customer validation was clearly not something we were tuned too), and eventually set up a PayPal donate button.
And I'm really proud of our community - we've been discussing ways to improve email very openly since we started. They drive ideas, and we implement them to create a very experimental product.
I'd really like to write up our experience for HN, including the experience of getting an invite to YC, but not a place. There are a lot of stories of how regular people - our customers - pulled a business out of a geek hobby, and lots of mistakes and missteps I've made that could have been avoided.
Email has been very closely integrated with task management in Outlook for a while now.
On the same note, I've been hoping that Google would flesh out Google Tasks for a while now -- technically Tasks ties in with Gmail and Google Calendar already, but that integration is fairly primitive, and Tasks is still missing extremely basic things like search, labels, and a usable (non-widget) UI in Gmail. Of all the projects Google is letting stagnate, this one hurts me the most. I could make great use of it if it were more complete.
I got the impression from a single conversation I had with Google back in January (please take this as the single data point it is), that they really did re-route the entire organization to focus on Google+, and were prepared to scale back efforts on Google Apps for at least a few months. For reference, the conversation was about them seeking 3rd party vendors to fill in the gaps in their offerings.
True that Outlook has excellent task management functionality, but not when you want to interact with non-outlook users, or even simply across corporate networks.
That's a very sensible question, let me take a stab at answering it.
So, for 99% of things, it's all stored on Google's servers. ActiveInbox is a lot of UI enhancements to create a new way of controlling your email, but it does it all with a clever use of Gmail's labels.
The only thing that relies upon the server is if you're a Plus user (including the free trial), to store your preferences on our server; and to store 'Conversation Notes' (a text box at the top of all conversations for planning next actions, a quick memo of what the entire thread is about, and links to related information if needed).
We are trying to figure out a way to do Conversation Notes purely with IMAP, but we haven't got a really fast/reliable idea yet, so we're sticking with our own servers.
But yes - for everything that is important to your organization, it's all labels.
I believe the fun-factor - or lack thereof :) - might have something to do with the fact that Monopoly's origins are supposedly as a warning of the perils of capitalism.
While the story is disappearing into time, and is perhaps an over-egged story of folk woman vs. corporate greed; there is a marked similarity between Elizabeth Maggie's "The Landlord Game" and what became Monopoly http://en.wikipedia.org/wiki/The_Landlords_Game (it appears an apostrophe is parsed out... it should be The_Landlord's_Game).
Its intent was to demonstrate how monopolies grow, and how once they exist they are hard to overcome. I.e. not fun. Which might explain something about Monopoly today :)
Disclaimer: I haven't built this yet (primarily because it's too hard today).
I want to build self-hostable servers, to give our customers the option of privacy and easier compliance.
In that arrangement, there'd be:
- Our main / central server, for regular SaaS customers. It also provides public assets ("knowledge bases" in this case, but it could be anything - even just licensing info) that all signed-in users have access to. This would be the iDP.
- Many self-hosted clones of our central server, per customer
Because the central server has the most up-to-date shareable assets, which might be ahead of any upgrade schedule a self-hosted customer has, they'd want their signed in employees to have transparent access to those latest ones too. I.e. without the extra friction of additional sign-in.
tl;dr the ability to offer our customers an easy self-hosted option of our Supabase platform (with limited federated access to central data) is highly desirable, now that even SMEs request better infosec. Doing it all inside a Supabase Docker - rather than mixing in Okta - is what makes it maintainable and easy to share.
--- EDIT ---
This use-case could be written more simply:
- There's a platform/app server (built on Supabase). Customers can optionally self-host it for their business.
- There's a data server (also built on Supabase, but not self-hosted), that provides shareable assets, even to self-hosted servers.
My goal is that it's _seamless_ for self-hosted users to access the data server.
So the data server would need to be an iDP.
My preference for Supabase to do this (instead of Okta), is because offering a self-hosting option is currently an intimidating maintenance burden, so fewer moving parts (no Okta) is desirable.