I am new to laravel passport and i am figuring out how laravel passport works
Question 1
Why save the personal access client id and secret in .env according to the docs here? if the id and secret is created by executing this command php artisan passport:client --personal and stored in the database
Question 2
According to docs, it is said to save it in .env file. which application is it saved in? the passport application or the frontend javascript application. I have 2 different projects one is the laravel passport(backend) and the other is the nuxtjs(frontend)
Answer 1
You should never hardcode secrets; that is one of the most basic security best practices. The reason behind that is that when you push your code into any remote(usually Github), you let anybody see that secret.
Even if your repository is private, you may not want all members to have access to it or if you decide to make it public you won't want to worry about secrets being leaked. So it's best to not include them in the code.
More about your oAuth secret key here.
Answer 2
It is not loaded to any application by default. What you're doing is just saving the information to a file called .env. You then have to configure one of your applications to load environmental variables from it, probably using a library(how laravel does it, how you can load .env files in nuxt.js.
In your case, the Nuxt app does not need to have access to that secret so there is no need to load it there.
Note that you will have to use .gitignore or an equivelant to your source-control system in order to prevent the .env file from being uploaded to a remote and avoid the problems of answer 1.
Related
I am using laravel to build an app in BigCommerce. I am able to get access token but I need to store that for future requests. What is the best possible way to store the app data for BigCommerce?
I've got this working by creating a DB schema in Laravel where in there are tables like stores, users, app_settings.
Whenever the user installs an app, I am storing an access token and other information like store hash in stores table and user details in users table.
Whenever the app is loaded I could get the store and user information via verify signed request payload. Using this I am able to configure my app settings for the user and store those in app settings table.
So when I create a Webhook for the store, I could get the store hash from response as producer key and accordingly I can find the access token for the store using store hash in stores table.
If you're git ignoring your config.json or .env files, you could store these there. However after speaking with one of our Developer Advocates, I wanted to pass along some best practice advice. :) You may want to consider using a secrets manager for option #1 in your decision here. A secrets manager meaning a tool to safely store these variables like Secrets in Github or Key Vault in Azure.
Also, this resource may be helpful to review for your use case. https://www.codementor.io/#ccornutt/keeping-credentials-secure-in-php-kvcbrk55z
I am trying to figure out how to handle the Password Grant Tokens in Passport package. Should i store the client_id and client_secret in .env file or fetch the values direct from the database while requesting for a the token?
It depends on what you are finally trying to achieve.
Passport tokens are always stored in DB, and this is the right place to retrieve them (unless you are optimizing your production app, to gain less db load).
So, if you want to build an api endpoint, you can safely store PASSPORT_CLIENT_ID in your .env.
And then, in your controller, you can easily retrieve all data that you may need.
How to do it? Please read my post, on how you can embed this in your laravel controller.
Passport is built on top of oauth2 server which has loads of features.
Most likely you won't need them all, so you can stick to the basic jwt authorization as in this case.
This approach would enable you to test your code against different CI environments, while not sharing any specific keys/tokens in your VCS, which is definitely a good practice.
Final note... Passport makes packages like dingo, tymon jwt, etc.. useless, cause it has almost everything packed in, and what really important is, this is the official Laravel package.
While you certainly can store the values inside your .env file, you should think these tokens as secrets you grant to other developers who want to use your API. What if everyday 50 developers want to register to use your API, will you add them by hand to your .env file? If it's only you / your company this kan be "ok", but I would store them in the database for scalability.
I would like to bring a login with Github and Facebook to my single page web app, the server is under my control.
In this tutorial
https://spring.io/guides/tutorials/spring-boot-oauth2/
they store the client_id and client_secret in a file.
Wouldn't it be more convenient if I stored these 2 in my backend database ?
Let's say someone who's not a programmer would like to register the web app to a new service , he could do that easily opening the database, he doesn't have to crawl into the backend project code.
If not then where should these 2 be stored ?
If you talk about the convenience, storing these in a property file is a good option. By doing so, the properties can be easily loaded into the application during the startup. If you change the values, all you need to do is just restart the app and the new values will be reflected.
I am not sure I understand your non-programmer related comment 100%. But IMO, for a non-programmer, modifying a file is much easier than modifying the DB.
Just to be more clear, the client id and the client secret represents the credentials of your application registered with the social media (like facebook).
Ans yes, you can store these in DB as well. But then, you need to write code to fetch these values from the DB and load into your application.
I'm trying to build an internal admin system to get to grips with creating a Laravel app from scratch. Currently everything is public so I'm looking at implementing a very simple login system.
There will be no DB connection needed as we want a single user. We'll store the relevant username and password in the .env file most likely.
I feel like I've looked everywhere and haven't been able to find any tutorials covering this requirement! From everything I've read it seems I have to use a 'custom authentication driver' or possibly build my own user provider class but I have no idea how to go about this task.
The idea is that if the app is expanded in future we'd like to be able to just go back to using Laravel's built in db auth functionality. For this reason it would be nice to retain all the common methods relating to checking the current user, using auth middleware on my routes and managing login tokens etc.
Thanks in advance for any help offered.
I have a github page for my organization where I would like to call data from a 3rd party api where I need an auth token. Can I publish this github page without having the auth token displayed on the public repo?
In short, no. If your GitHub repo is public, all its assets are public. You can make the repo private and it will still publish on GitHub Pages if named with the username.github.io convention or if it has a gh-pages branch. While that's an option, that's not necessarily the right thing to do.
If your key is in your GitHub Pages repo, it sounds like it's used for client-side API calls in JavaScript. If so, your auth token is publicly visible whether it's in your public repo or sent in your client-side files to the browser. This is usually fine. The third-party API might have generated the auth token based on your website's domain, and restrict calls using that token to pages originating on your domain. Otherwise, they might require the auth token only for logging requests and monitoring usage.
If the auth token is truly meant to be private, then you may need to write private server-side code to call the third-party API. Your GitHub Pages site could then hit your service for the data it needs. I've had to do that before where the web API had security concerns, but I still needed to retrieve non-sensitive data from the client-side.
In short yes, you can store the auth token in an environment variable and use gitignore on the .env file to hide the auth token in the public repo. Refresh the auth token on the client-side API then push changes to the public repo and redeploy your updates to the gh-pages branch. I've provided an example of this process below.
NOTE
If you committed a password or API key, change it! If you committed a key, generate a new one. Reference general best practices on GitHub.
If using React for your app, SKIP steps 1 and 2 as React already comes pre installed with custom environment variables. Reference Create React App.
The full explanation can be found below:
1. Install dotenv dependency in application root directory (will be using Node.js for this example) Reference npm, run command:
npm install dotenv
2. Add code below to import statements in index.js file.
require('dotenv').config();
3. Create .env file in root directory of app and add auth token as variable. Note when using React you must prepend variable name with REACT_APP_
AUTH_TOKEN=987asc8iks0lenv7
4. Use console.log() on process.env to check if the variable was stored correctly.
console.log(process.env.AUTH_TOKEN);
5. Update all references to auth token in application code.
OLD VARIABLE: const auth_token = '987asc8iks0lenv7';
NEW VARIABLE: const auth_token = process.env.AUTH_TOKEN;
6. Create and add .gitignore file to the root directory of application and add code below to have git ignore the .env file where the auth token is stored.
.env
7. Add, commit and push updates to application master branch on GitHub.
8. To deploy or redeploy updates to gh-pages branch. Use command below.
npm run deploy
The answer of Ashen won't work for this use case. Secrets configured through Github are only available to Github Actions (see documentation), and because of that - in practice - mostly to CI/CD-like applications. Not for e.g. client-side API calls.
The GitHub Actions should facilitate your need.
You can add secrets using the visual workflow editor or the repository settings. Once you create a secret, GitHub encrypts the value immediately and you can no longer view or edit the value. Anyone with write access to a repository can create and use secrets in that repository.
However, the GitHub Actions is currently available in public beta and therefore should be avoided for high-value workflows and content during this beta period.