PromptPal
The metamask / etherum address for login requirement is a no-go
I'm looking for a prompt management tool and the features noted on the readme sounded interesting until I read about the Metamask requirement.
If your target audience are cryptocurrency projects, then that's fine, but if not, having that requirement would strike this project off the list for many. Why tie your auth this way?
Hi @theogravity , i'm sorry for late reply. i'm on a vacation currently.
for the metamask as login method. what I think is I only want a very very simple way to login. if a user have correct private key then he/she can login seamlessly, without any password or 2fa something.
and there are some technology like passkey can do it also, but can not easily migrate to another user and cannot be pre-setted.
so the final solution is this one. user can setup some address(publicKey) when server startup. after that user can login without any password.
and yes, this method is not a common way. I still think how to design a simple and secure auth way.
It's not simple for those who do not use web3 tech at all. No one outside of crypto folks is going to want to download and set up Metamask or some other ETH wallet to simply log into your product.
If it's a huge hassle, then integrate with a 3rd party like Google / GitHub, etc. No need to manage anything other than their related account ids just like an ETH addr.
it's impossible to integrate with 3rd party like Google/GitHub if this product must be on-prem first. and I don't think it's hard to learn the web3 for engineers. technically, it's just another version of RSA.
btw, it's not my product. user can freely deploy this app to their own server/cluster without any tracking, report, or 3rd party apps.
it's impossible to integrate with 3rd party like Google/GitHub if this product must be on-prem first.
It is not impossible. There are lots of on-prem products that use Google or GitHub as a login. When I was at Yahoo we used GitHub Enterprise internally, and you'd use your internal GH enterprise login to other systems if Yahoo wasn't supported as a login.
Lots of companies including the one I work at uses Google Workspaces and we use our GMail logins (OAuth2+OIDC) a lot with our on prem stuff. I have SaaS customers who want to be able to use MS Azure 360 (OAuth2+OIDC) or Active Directory (SAML) as a login type as well.
No company I have worked at / with has ever asked for a web3 login as the primary means of auth; no one has asked for web3 support at all. The common login types are going to be OAuth2+OIDC-based or SAML-based.
I know this from personal experience as I've built entire auth infra from scratch for both Samsung and the company I currently work at.
This is your project, and you're free to do what you want with it, but if you want wider usage (or usage at all), then really consider adding OAuth2+OIDC support (eg Google, Github, MS 360) at the very least.
and I don't think it's hard to learn the web3 for engineers. technically, it's just another version of RSA.
You really need to talk to others who would potentially use your product and ask them would requiring a web3 login be a deal breaker. Talk to actual people in the AI space who'd use your product, not crypto folks.
It's going to be a deal-breaker because it's another auth system IT needs to manage (eg someone is going to have to maintain a whitelist of addresses and a process to de-provision when an employee leaves the company).
Companies have centralized auth for a reason - it's easy to manage access control and disabling infra-wide from one place vs multiple, where if you forget to disable access in another system that could mean unauthorized access should that employee have something against the company.
All in all, I'm saying it's fine to offer web3 as a login type, but it shouldn't be the primary and sole option for auth. You also need to allow IT to disable the login type if they only want to allow their own internal auth.
it's not my product
It is your product, you're working on it and own its development. I think you may have misunderstood the phrase? I've never heard of "your product" to mean it's the user's app because it's customizable.
Also be aware that some companies may have browser policies in place that prevent installation of extensions, so Metamask would be out of the question.
- https://learn.microsoft.com/en-us/deployedge/microsoft-edge-manage-extensions-policies
- https://www.thewindowsclub.com/prevent-users-from-installing-extensions-in-google-chrome
- https://www.thewindowsclub.com/disable-add-on-installation-firefox-group-policy
OK, I think I understand your advice.
thanks for your suggestion. it's very useful.
I'll consider adding support for the OAuth2+OIDC-based auth system. After your explanation, I realized that the auth system I currently support is probably not a good way.
thanks for your advice again.
and "it's not my product" in the context I want to say is the deployment. since it's not a SaaS product, I do not own the data. 😂