Using custom config for Nexmo from $notifiable in Laravel notifications - laravel

I'm having a hard time sorting out how to make Nexmo use custom settings from $notifiable i.e. App\User while sending out notifications. Laravel by default expects the Nexmo config (API key, secret) to be set in services.php and Nexmo driver uses the config from there directly. Although updating the config in runtime helps setting the values for the first time (if not set in services.php) but the same config values are used for all events. Ideally the config values should be used directly from the notifiable.

If I've understood the question correctly, you want to use your customer's API key and secret rather than using a single value for all customers.
If you'd like to use multiple API keys and secrets you'll need to use nexmo/client directly (github repo):
$client = new Nexmo\Client(new Nexmo\Client\Credentials\Basic(API_KEY, API_SECRET));
You can fetch the credentials from the database and add the client instance to the container by writing your own small service provider. Here's the one that nexmo/laravel uses. This one is complicated as it has to support every possible authentication combination.
/via https://github.com/Nexmo/nexmo-laravel/issues/27

Related

Standard way to store session data of a visitor on system built with Laravel API

I have built an API with Laravel + Sanctum consumed by a React Native app. I need to store the user's country, regardless they are logged-in or not. Will have to check the visitor's country on each request to send them country-specific products in response, need the user be identifiable like a web session.
How/where to store the info as session is not available or a viable option to store the data on the server with regard to API?
I know it's not a Laravel specific question but I could not find any standard answer online.
You grab their IP address in Laravel via the request()->ip() method.
There is also a package you can use in order to map their IP address to the country they are from: https://github.com/Torann/laravel-geoip
Make an API endpoint which uses that package to map the request IP address to the persons country and store the response as a cookie in your React Native app.
When someone loads your app, check if their country cookie is set. If it isn't, call your API endpoint to get their country and store it in a cookie.
You can use Auth for Authentition
composer require laravel/ui
php artisan ui:auth
You Can Also Use Session
Session::put("variable", $valueVaribale);
Session::get('variable');

Laravel - check if other people are using my API and who

I have an API and I'm not sure if other services are using it too. I don't want other people to use my server resources and I would like to check that.
Assuming I have a method in a controller, how I can check who accesses this method where the request is not from my domain?
How I can allow connections only from my website/app and refuse from any other source?
Each request has a Host header you can use that to know which domain is using your service.
if you want to only allow your domain to access the service then edit the CORS settings. I'm assuming you are using barryvdh package
in config/cors.php
change the value of
'allowedOrigins' => ['*'],
to your domain instead of * wildcard
You can also use extended library (like so: https://github.com/chrisbjr/api-guard) to add API key to your app so only those who know it can make requests to API.

Cloud function authorization vs validationHandler

Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.

How can I hide API secret key when sending AJAX requests?

I am about to start working on a project, which is basically a web interface for a mobile banking application. The API is ready, I only need to provide the frontend part of the web application. I was going to make it using Backbone/Angular/Ember, but started to worry about the security.
Particularly, the following. As a rule, every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key. If I put the logic of how this param is calculated into one of .js files, anyone could potentially access some sensitive data using tools like Postman or even browser console. How should I go about this issue? I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
every API request must contain a parameter method_code, which is calculated as hash of user token, method name and secret API key
I could have a server-side script generating the method_code for me, but is it possible to make it accessible only to my web app's requests?
Yes, the server-side script would be the way to go if you do not want to expose the secret API key within your client side code or request data.
User token can (presumably) come from the user's session cookie value? So simply have a server side method that takes the method name and then returns the method_code calculated from the secret API key (kept server side only) and the user token.
The Same Origin Policy will prevent another domain making a request to your API and retreiving the method_code. I'm also assuming the API and front-end code runs on the same domain here, although if this is not the case you can use CORS to allow your front-end code to read and retreive data client-side via the API.
You can try to generate a token based on security factors and encrypt that and use it in your requests to identify your clients and valid requests.

cant retrieve EventBrite access token

I was trying to authenticate a user using EB's loginWidget example, and as I debug,
I discovered that getAccessToken() request always returns a null
even though a session was successfully created.
The parameter I passed in to the loginWidget are: user secret I got from the app key, and the app key.
Are you using PHP? If so, this guide should have you covered:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md
By default, PHP's $_SESSION store will be used to save each user's access_token. You'll need PHP session support to be enabled in order to get the basic demo working:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md#2a-using-phps-built-in-_session-storage-optional
PHP's default $_SESSION storage definitely has a few trade offs. If it is not your preferred data storage system, you can provide your own data-management callbacks, allowing you to store the access_token in a cookie, in your database, or in any other location that works well with your system architecture. More information is available here: https://github.com/ryanjarvinen/eventbrite.php/blob/master/OAUTH2-README.md#3-define-data-management-callbacks
Here is a basic implementation example, which takes advantage of the default $_SESSION store:
https://github.com/ryanjarvinen/eventbrite.php/blob/master/examples/oauth2-login-example.php

Resources