I'm currently trying to dev a website allowing people to buy things that are available on the web site by using tokens from our project. (so it's just about sending tokens, not a trade between tokens and a NFT).
I've done almost everything needed, and everything works using SOL. Now i want to switch the payements to our own custom token.
I've digged every posts on this forum and tried all of them but still couldn't find something working for me.
The problem is that all those answers use a hardcoded private key or the Wallet Interface which requires a Signer (keypair). Since our users will log on the site thanks to phantom it's not possible for us to get that secret key. Have you got any idea on how to implement that custom token payement?
Thanks in advance.
Checkout the solana wallet adapter https://github.com/solana-labs/wallet-adapter you can use the wallet object to sign your transactions. They have an example in the readme to transfer SOL, transferring an spl-token is very similar, i often use https://github.com/solstar-tech/easy-spl which works well together with the adapter.
Related
I have a current setup with Stripe and Laravel as a backend. Everything is working perfectly and as expected but I have a question regarding security.
As I have a React frontend to take payments, I am using the package #stripe/react-stripe-js which is Stripes official package.
With the package you obviously have to load in Stripe and pass in you public key and in this scenario the connected accounts id. I've done this thus far, but the frontend uses a API call to see what the order is and the price etc, with that call sits the connected accounts id so I can append it into the load stripe method.
const stripePromise = loadStripe(
'xxxxx',
{
stripeAccount: 'xxxxx',
}
)
As this has to return in plain text so Stripe can read it, I wanted to know other peoples opinions on whether or not this is safe to expose the connected accounts id.
I can't really see any other way around it, I could encrypt / decrypt somehow but even still, that's accessible to the client side version so it is still visible.
I've read the Stripe documentation which can be found here https://stripe.com/docs/connect/authentication#adding-the-connected-account-id-to-a-client-side-application and it seems as though they hold it in plain text.
With all this mentioned, the secret key is obviously never exposed to the frontend and all of that creating the Payment Intent is handled in the backend.
Yes, it is fine to keep the Connect account ID public.
A Stripe account ID (e.g. acct_123) is intended to be used client-side as well as server-side, with your respective Stripe API keys.
The Account ID will only work if your Platform is "connected" to that existing Stripe account, otherwise the account ID is useless if used with an unrelated Platform's API key (the Stripe API validates that and returns an error).
There seems to be a lot of documentation lying around everywhere about how to use Google Cloud Platform and its fancy AutoML service. But I couldn't find anything that is solving my problem of trying to get a prediction from a trained model on AutoML via a local website. The website code is in this link: https://pastebin.com/xsfkYf6C
All I get in return from uploading an image and clicking "process" button on this site is:
{
"error": {
"code": 401,
"message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
"status": "UNAUTHENTICATED"
}
}
I surely have made some mistakes somewhere, but I'm completely clueless as to how I would fix this or maybe because I'm just too dumb to figure it out yet. My research has yielded none to very little results. This article might be of some help to clear things up about AutoML Restful API: https://cloud.google.com/vision/automl/docs/reference/rest/v1beta1/projects.locations.models/predict
Appreciate any of your suggestions and code fixes.
Thanks so much and have a great day!
You need to pass your api key to REST API call like this:
https://automl.googleapis.com/v1beta1/projects/a...1/locations/us-central1/models/ICN...1:predict?key=API_KEY
To create an API key you need a Google Cloud account since it's only free up to a certain point and then you will get charged for.
Therefore you should secure this key and make sure it is not visible publicly(so don't put in your html source code, backend should handle this call).
More details here
The error could mean that you are using an API Key or the token you provided is wrong/malformed. I think that creating a token using Playground, ServerSide, Javascript, etc. will fail due to there are not OAuth2.0 scopes for AutoML, maybe because is still in beta release.
Keeping in mind that a token generated from gcloud it works, I can suggest generating programmatically a token impersonating a service account to generate the token, this example contains all the pieces of the puzzle. This means that your user could generate a service account token on behalf of your service
Points to consider when executing the code:
Enable the Identity and Access Management (IAM) API.
Update the code according to your own configuration, project and json file.
Use the generic scope: https://www.googleapis.com/auth/cloud-platform as the jwt_scope.
IMPORTANT: The python code it is using urllib and httplib, which means that it could be translated to a POST requests with some extra effort (to be used in your javascript)
Let us know if it works for your specific use case!
I want to be able to sign into multiple accounts at the same time (think of how gmail lets you swap between signed in accounts). Is this possible/supported using Cognito? (I only need to be able to use one at a time)
Further, is there a way that I can give the user a challenge when swapping to another account such as a pin code (dumbing down my use case here).
This whole managed user accounts thing is very different to more traditional apps given that the authentication is no longer done on my server side... except for the challenge. Is it possible to mix the server/non-server based cognito authentication like this?
I'm going serverless with lambda and typescript.
Some guidance on how I could achieve this would be much appreciated
Suppose you have 2 applications and if both of them are authenticated using the same userpool, then I don't see an issue in this. All you need to do is store the access id post authentication in the Application 1 and look its validity before allowing the same user to use Application 2, which in turn is using the same userpool.
I believe that you can achieve the challenge usecase by customizing the userpool workflow using the pre-authentication lambda.
Customizing User Pool Using Lambdas
I need to access the active version on SAP Cloud Platform of HTML5 apps through an api.
I know for the java apps you have the lifecycle api: doc
But you can't access HTML5 information with this API.
What I found is this service: https://account.hana.ondemand.com/ajax/getHtml5AppDetails/{subaccountName}/{appName}
This will return a JSON string with the required info, but I'm not authorized to access this page, although I have all the possible admin rights.
So I'm wondering If any of you has any idea to solve my issue, and other people's issues.
Well, we needed something similar and used this kinda hack to get the active versions via WebIde Api (need basic Auth to login) replace XXXX with your account
https://webide-XXXX.dispatcher.hana.ondemand.com/api/html5api/accounts/XXXXX/applications
You get back a json array with all your applications of that sub account, including active version and other interesting information
Hope it helps ;))
Regards Mathias
You could create a HTTP Proxy Servlet based on https://github.com/SAP/cloud-connectivityproxy that provides read only access to https://dispatcher.hanatrial.ondemand.com/hcproxy/b/api/accounts/<subaccount>/applications/<app> for your app.
I'm making an open source Node module that will require access to each user's private Google Drive files. I've been trying to wrap my head around all of these different authentication types, and have come to a road block. From what I've gathered, there are two primary types of authentication
I, the library author, provide in my library the public and private keys necessary to authenticate each user with OAuth2. This means giving them a URL to go to to give my app permission to access their data, and have them copy and paste an access code back into their terminal. I was able to run through this tutorial and get it working, but this method seems dangerous, because of the keys I have to package with my library, and unnecessarily difficult.
Have the user go to the Google API console, get their own API key, and provide that to my library through some sort of configuration file. No URL redirection, no copying and pasting, just some private credentials that only they have access to.
2 sounds a lot better to me: This library has absolutely nothing to do with me once it's in the user's hands, so it feels incorrect to have them authenticate with me. But from what I can find, the only way to do this with Google's API is to create a Google Service account, download the JSON they give you, go through a flow similar to the top comment on this blog post, and then manually give the service account email access to my personal Google Drive files. This seems hacky, and a lot of work to gain access to my own private data. Is there a better way to go about this? It seems strange to me that this fairly standard flow in other APIs is only available in Google's API through service accounts, but maybe there is a way and I'm just not seeing it. I'm fairly new to authentication, so any help at all is appreciated. Thanks!
First off I want to say that you cant release your open source project with the client id and client secrete that you created on Google Developers console this is against googles terms of service.
1.Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep
your credentials confidential and make reasonable efforts to prevent
and discourage other API Clients from using your credentials.
Developer credentials may not be embedded in open source projects.
My Answer on another question about exposing client id in open source projects.
Second you could instruct your users to use either Oauth2 or a service account or both its really up to you.
If the user will only be accessing their own data and wont need to access someone else's data then they can use a service account you will need to instruct them in how to share a folder on Google Drive with the service account. However from your side permissions can be tricky when they are uploaded the service account will own the file uploaded to the users google drive account you will need to have the service account add permissions for the user so the user will then also be able to access said file.
The easiest way to go will be Oauth2 when the code uploads files they are owned by the authenticated user so you wont have the same permissions issue you had with a service account.