I am currently thinking about creating a dapp that connects to a phantom wallet on solana. A user account will be created upon connection Signup/Login a User. I'm not sure how to verify the public address. Wallets will pass information to the frontend and i would have to forward this information to the backend, thus it is manipulable and useless... How do I prevent people from sending fake addresses to the server and signing up to any account they want? I thought about signing a message but why is this not done on e.g. opensea.io(Eth/Metamask)?
How do I prevent people from sending fake addresses to the server and signing up to any account they want?
Make them sign a message.
I thought about signing a message but why is this not done on e.g. opensea.io(Eth/Metamask)?
This is not done on OpenSea because OpenSea does not create or manage user accounts for its users. The app relies entirely on the PKI of the user's Web3 provider (such as MetaMask).
Ask yourself why you need to create a user account for your users on your backend. If you need to create such an account, then make the user sign a message. If you don't need to create a user account, then just let the user authenticate directly with the blockchain using their own PKI like OpenSea does.
Why not create the Keypair (public + private key) in the backend itself? Since you're creating a new account on signup. Send a request to the backend and create account and return the public key to the user.
But instead of doing this. You can ask the user to create a new wallet and singup using something like a phantom wallet. Did that help?
Related
How to send service emails
from my backend with smtp.google.com or Gmail API while making sure
the secret stored on the backend server can only be used to send emails from a specific sender?
Goal
send user account activation emails from my backend
use smtp.google.com or Gmail API (i.e. no own SMTP server)
authenticate with OAuth2.0 (i.e. don't enable "less secure apps")
Current state
implemented the email sending part
for testing, I created a noreply#**.** Google Suite account
for testing, I generated an accessToken via OAuth2 Playground
using the accessToken I can send emails via smtp.googl.com
Problem
Google suggests to use a service account for this
But to send emails from no-reply#x.y I have to enable Domain-wide Delegation
Domain-wide delegation allows to impersonate every domain account
the secret stored on the backend should only allow to send mails from no-reply#**.**
Lets start with send user account activation emails from my server I am gong to assume that you have a web app. This web app allows users to register with your system. Now when a user registers with your system you want to automatically send them an account creation email. Your idea is to use Google rather than setting up your own smtp server and sending these emails from your own system. Not a bad idea really.
Lets think about this for a minute the emails would need to be sent automatically so you need some kind of service sending them. To do that you want to use a service account. Again this is a great idea using a pre authorized service account that you will not need to have a user to authorize the app.
The only issue is that service accounts do not work with normal gmail accounts. To use a service account with Gmail api you need to use a google workspace domain account. The workspace domain admin would then be able to add permissions to the service account letting it act like a user on the domain. In this case your idea of no-reply.
So your workspace domain account would have a user called no-reply. The domain admin would then configure domain wide delegation to the service account allowing it to pretend that it is the user called no-reply. For all intents and purposes the service account is the no-reply user. It will be able to send mails as if they are coming from that user.
For all this to work you will need the workspace account with that user.
Have a look at the following link, it's actually one of Google's better examples it shows how to set up the delegation.
Perform Google Workspace Domain-Wide Delegation of Authority
Here you create a service account with credentials, allow this account to impersonate other users (e.g. the no-reply user), to only use the Gmail API and to only use it to send emails.
the documentation is a bit outdated, you can skip the step Grant users access to this service account and create the service account key afterwards via the service account edit function: Manage keys
in the step Domain wide delegation you need Google Admin not the Google Cloud Platform Admin Console as in the previous step
Just remember to swap out the lines about
https://www.googleapis.com/auth/admin.directory.user,
https://www.googleapis.com/auth/admin.directory.group
and use
https://www.googleapis.com/auth/gmail.send
instead as you want to access the Gmail API and only allow the service account to send (not read) emails
tip
in the sample code in that link
.setServiceAccountUser(userEmail)
userEmail is the email address of the user you want to impersonate in this case no-reply#x.y
So I guess what I am saying is that what you want to do is definitely possible, however, it may be easier just to set up your own SMTP server.
Trying to setup an app with a sandbox account on PayPal. I already had a Business account with PayPal and have created a new application under the Sandbox.
I am provided with 3 credentials by PayPal:
Sandbox account which has the appearance of an email address
Client ID
Secret
However, using Omnipay with Laravel and it asks me for Username, Password and Signature in the config/env. I have some legacy prod credentials which look nothing like those provided by PayPal above, so can't even make an educated guess.
Thank you in advance.
Client ID/Secret are API credentials from a REST App (which if for sandbox mode will be tied to a particular sandbox account when the app is created)
For the old classic NVP/SOAP API Username/Password/Signature credentials, go directly to the sandbox account list and in manage accounts (...) select View/Edit account, second tab.
We are integrating Google Calendar with our room booking system. Users in GSuite domain should login on our reservation screen and book a room. So far I made use of an service account with domain wide delegation to impersonate the users (the setSubject() method, passing the e-mail address of the impersonated user). Everything works, although this way we cannot verify if the user we want to impersonate is logged in successfully or not, the event will be just created with him as the organizer, because setSubject() only requires the email to work properly.
In IBM Domino, when using an Java XPage I was able to compare passwords of the user, not in plain text but there was a function which compared plain text with user's hashed password and returned true if they were equal.
As I see Google doesn't have such a thing if I'm right. How could I check if the user can successfully log in programmatically?
If you want to perform actions in Google Calendar on behalf of a currently logged-in user from a web browser, you might want to use OAuth2 for Web Server Applications instead of using a service account with impersonation.
With Google service accounts, Google generates the public/private key pair associated with the service account and passes that along to the end user who wants to make API calls. And its up to the end user to keep the keys safe. Is it possible to generate a service account and an associated client, but provide a certificate that Google can use to validate the service account client making the request? The problem I'm trying to solve is not to exchange any private keys.
Also is it possible to scope the users a service account has access to? For example if I wanted to create a service account that only has impersonation api access rights on a sub set of users on the Google domain. From what I've read if you create a service account with domain wide delegation, the service account has impersonation api rights for ALL users on the domain.
No, you cannot associate service account and provide a certificate to validate the client request. As stated here a service account's credentials is unique and at least one public or private key pair. To generate service account credentials, go to Google Developers Console. In the Create service account window, type a name for the service account and select Furnish a new private key. Your private/public key pair is generated and download to your machine. It serves as the only copy of this key. You are responsible for storing it securely. For more details about service account credentials in the Developers Console, see Service account in the Developers Console help file.
I am trying to use google api for getting new emails from gmail account. However reading the docs I found that there are two types to access api the first one without authorization (with json credential) and second one one is Service Account (with p12 certificate and secretkey)
Can not understand what the difference between this access? What exactly should I use?
Thanks
Oauth2 is the first type you are looking at. With Oauth2 a consent screen is displayed to the user who must approve your access. Usage you want to access a users Gmail account, you want to access a users google calendar, you want to access a users google drive.
With a service account access is pre-authorized by taking the service account email address and adding it as a user for data in question. Usage: You want to allow other users to upload files to your google drive account, you would add the service account email address to a folder on google drive then the service account will be able to upload to that folder with out having to prompt any user for permissions.
Use Oauth2 when you want to access a users account, use a service account when you want to access an account controlled by you the developer.
If you want to access a users Gmail account you need to use Oauth2 you cant grant another user access to your Gmail so there is no way to give a service account access to it.