I have a dApp where you login with your Elrond wallet and you generate a signature (containing the wallet address and some more data).
While making requests to an endpoint, I pass the signature on payload and I need to verify it on the backend (so you can't change the wallet address and make requests on someone else's behalf).
I am using PHP with Laravel Framework.
How can I verify the signature on the backend and get the wallet address?
i've written a Laravel SDK for Elrond that can help you with that, or you can copy the logic from: https://github.com/Superciety/elrond-sdk-laravel
note: it's still work in progress & mostly undocumented - i'd welcome any contributions
to verify signatures coming from your dapp, you'd use it this way:
$isValid = Elrond::crypto()->verifyLogin($token, $signature, $address);
where $token is an arbitrary string unique to the user's session to avoid replay
Related
I have a following issue:
I'm writing an integration test (cypress) for resetting password. The issue is, that right now I send the url (with key needed to reset the password) to users email. Email must be real (so eg. something#something.comething).
I wanted to use something like mailhog for this sake, but I don't think it's possible in this case, since I send api request from frontend to backend with en email that requested password change, then backend sends a message to this email address with the url (so I can't do it directly from frontend and I'd like to avoid backend changes in this case).
Is there some service, that I could use, that would eg. run in kubernetes pod or just straight on localhost, to "pretend" to be a real email, so I could signup with it and then reset the password for it? It must have some api, that would allow me to get the email value (for the sake of getting the url with reset key).
Not sure if the title summarises my question well.
Basically, I am trying to authenticate routes such as checking if user exists etc. I only want to allow
requests coming from my frontend application to be approved, but, since no user is signed in there is no token to send.
Api request -
mywebiste/checkUser/email
This route is unprotected on my backend because no user is logged in.
BUT I want to protect this route, in such a way that it's accessible only from the frontend.
Some ideas I came up with were adding specific headers tag from the frontend and check them on the backend, but that could be easily replicated, is there something more secure like using tokens etc.
I am using React and Node.js
Same origin policy is going to give you some basic protection, but basically if an API endpoint is exposed publicly, it's exposed publicly. If you don't want that route to be publicly accessible you need to add access control.
If you use that route to check if a user is already registered, you could, for example, merge it with the user registration route and send a different error code if the user already exists (which is not a great idea because it leaks which emails are registered on your system).
You can verify that a request was originated by a user (by authenticating him) but you cannot verify that a request comes from a particular client because of these two reasons :
If you include some API key in your client (web page or other), it's easily retrievable by everyone (the best thing you could do is offuscate it which makes things slightly harder but still possible)
If you send an API key over the network it's easily retrievable as well
The only thing you could do is prevent other web pages from calling your backend on behalf of the user, by using CORS (which is actually active by default if you dont specify an Access-Control-Allow-Origin header)
I ended up creating a kind of working solution, so basically, I create a new base64 string on my frontend and attach that to the header while making a request to the backend. The base64 string is different every minute, so even if the header is copied, it differs every minute and is combined with your secret key.
I have made a package so that people can use it if they want - https://github.com/dhiraj1site/ncrypter
You can use it like so
var ncrypter = require('ncrypter');
//use encode on your frontend with number of seconds and secret key
var encodedString = ncrypter.encrypt(2, 'mysecret1')
//use decode on your backend with same seconds and secret
var decodedString = ncrypter.decrypt(encodedString, 2, 'mysecret1');
console.log('permission granted -->', decodedString);
In Swagger I have had problems to configure the authorizations.
In Available authorizations there are two fields to fill:
subscription_key (apiKey)Provide your cognitive services subscription key here.Name: Ocp-Apim-Subscription-Key
token (apiKey)
Provide an access token from the JWT returned by the STS of this region. Make sure to add the management scope to the token by adding the following query string to the STS URL: ?scope=speechservicesmanagement
I did not find it clear where I have to get this info.
Could someone help me?
The two paramters can be found as follows:
1. subscription_key parameter: this can be found in Azure portal> Navigate to the Speech service that you must have created (Cognitive Service) or see here to create new Speech service > use the value from Key1
Mine looks like below :
Things to remember :
The speech to text api (especially conversational api) is supported only in specific regions, I chose centralus.
The pricing tier should be S0 Standard to get the apis working (atleast for conversation apis)
2. token (apiKey) parameter :
You will need to generate the token by sending a post request to the speech service endpoint (see image above for location of endpoint url).
Add your subscription key as a header.
The post request will generate the access token as response
Things to remember :
As instructed in swagger, remember to add the query string of '?scope=speechservicesmanagement' to your endpoint url before generating the token.
ex: https://centralus.api.cognitive.microsoft.com/sts/v1.0/issuetoken?scope=speechservicesmanagement
All I found was with php and node.js (which is based on js, so it should be fine), but I got across this library:
<script type="text/javascript"
src="//media.twiliocdn.com/sdk/js/client/v1.4/twilio.min.js"></script>
What is the relavant JS code to make a "send sms" request?
This is the php I found:
<?php
require __DIR__ . '/twilio-php-master/Twilio/autoload.php';
use Twilio\Rest\Client;
$client = new Client($sid, $token);
$client->messages->create(
'+15558675309', // number to send to
array(
'from' => '+15017250604', // your Twilio number
'body' => "There’s something strange in my neighborhood. I don’t know who to call. Send help!"
)
);
Thanks.
Twilio developer evangelist here.
We don't recommend that you use the Twilio REST API for sending SMS messages within a public HTML page. If you do so, you will expose your account credentials publicly and a malicious attacker could steal them and send messages or phone calls on your behalf, using up your credit and potentially spamming people.
The JavaScript library you found there is for you to use to make phone calls from within the browser using WebRTC. This is built to not leak your credentials as you need to generate a token server side that can be used to authenticate users.
I recommend you check out the SMS quick start guides in a language of your choice to see how you can write server side code to send messages.
Setting up a payment form with the Braintree v.zero SDK:
braintree.setup(response.value, 'dropin', {
container : 'xyz',
onPaymentMethodReceived : function(payment) {
pay(payment.nonce);
},
});
After entering payment information, the form shows:
...but only until the page is reloaded. Is there a way to initialize the dropin payment form to list a customer's existing payment methods?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
The key would seem to lie with your response.value (i.e. your client token). I would guess that your server code used to generate it isn't specifying a customerId for that user.
From the Braintree documentation on generating client tokens:
Your server is responsible for generating a client token, which contains all authorization and configuration information your client needs to initialize the client SDK to communicate with Braintree. Including a customerId when generating the client token lets returning customers select from previously used payment method options, improving user experience over multiple checkouts. Set Up Your Client covers the client side of the exchange.
Bottom-line: Drop-in will display multiple cards if you generate your Client Token using the customer_id that matches your customer.
client_token = braintree.ClientToken.generate({
"customer_id": a_customer_id
})