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.
Related
I'm building the backend with laravel and then using Vue as front-end. Data is accessed over api calls using axios. Now I have this relatively simple task but I can't seem to find the proper solution. I want one of the routes to be easily consumable by Vue compoenents without the need to log in, however I don't want that route to be publicly available for anyone to use.
Things I have tried:
Using passport to protect my routes and then use passport's CreateFreshApiToken middleware. Protection works fine, unauthorized users are not able to access the routes, however I don't get laravel_token in my cookies and therefore I can't get access to that route if I'm not logged in.
Use passport's client credentials grant access. Works fine and the way I want it to work but doesn't really make sense because if I hardcode the client_secret - anyone can access it and then use it to access protected routes. If I make a proxy-like solution, to call a controller method, which would issue a valid token and thus not exposing client_secret to front-end but then anyone could just call that route which issues the token and it would be pointless once again.
Apparently the answer is pretty simple and I was overcomplicating things. I don't know if this is the right/elegant way to do this but basically. If you don't need your api to be accessible from other applications (which I didn't) we can just put routes in web.php instead of api.php. This will ensure that web middleware is used and so it will use the basic csrf token validation, which is totally sufficient for protection against outside requests. You can also leave the route in api.php and just use web middleware on that route. The outcome is exactly what I needed - application is getting data over a route without any need to login AND that route is not available over postman or anything else.
I have created two lambda functions
register
login
and both of them are getting triggered from respective "Http APIs" in the API gateway. I have set up the stage for both of them as prod. Now I want to call them using my custom subdomain e.g prodapi.mydomain.com by setting the path as "v1"
prodapi.mydomain.com/v1/register
prodapi.mydomain.com/v1/login
I am able to achieve it for a single API but when I try to do API mapping for the other one using the same path, it doesn't allow that and says "ApiMapping key already exists for this domain name".
Any suggestion on how to achieve this?
can you share the endpoint url, before adding the subdomain, and after adding the subdomain
And can you explain your endpoints, how it should look like before adding the subdomain and after
I want to use Nuxt.js for my frontend and laravel sanctum as my backend authentication provider. How should I set the SESSION_DOMAIN key in the .env file in my laravel project.
Also should I edit anything in the server object part in the nuxt.config.js file to make this work?
When you use Sanctum with SPA, such as Nuxt, you've the option to use either API or cookies/sessions. If your application is a first-party application on same top level domain, Laravel recommends to use cookie based approach so you can take advantage of CSRF protection. Axios and Angular Http libraries handles CSRF out of the box, so you don't have to worry too much about handling the requests headers [1].
In your case, I assume your application is first party and is on same top level domain. So your SESSION_DOMAIN value would be for example .domain.com. Also you'll need to set SANCTUM_STATEFUL_DOMAINS=domain.com as well. Usually your SESSION_DOMAIN will have just the main domain your application uses on, while SANCTUM_STATEFUL_DOMAINS will have all the subdomains (if any), that your frontend uses.
To work with Sanctum, we should be familiar with a few things first. We must use our SPA and API backend on the same domain, like frontend on domain.com and API on api.domain.com. We can not set frontend on domain.com and backend (API) on another-domain.com. The client must be able to include cookies with each request being sent to the backend.
session domain is the front-end domain name without protocol and port.
When you are working on local you must set it to localhost and when you are working on server you must set the domain name.
please follow this example of nuxt-laravel-sanctum-auth
I have separate backend and frontend. However, they run on the same server (this may change in the future). The backend serves as an api and is powered by Laravel. Frontend by Nuxt (Vue).
I wish only my Nuxt application could access the api. How can I configure Laravel to only return data if the request comes from a Nuxt application?
I thought about adding a special token to requests, but the user will be able to check what request is coming out and capture the token. Can anyone give me ideas how this can be solved?
You must be knowing about CORS. So in your Laravel Server, allow requests from only the frontend server's domain like this:
Access-Control-Allow-Origin: https://www.example.com
Simplest solution would be to add serverMiddleware in the nuxt project and route all the requests to the "real" api through it. Clients will hit the internal nuxt api and they will not be able to see the actual request made to the real api. There you can also add the token you are talking about for extra layer of security.
I'm running through cooking up my own test IdentityServer, but I'm hitting a snag. The ClientUri and RedirectUris must be specified for every browser based client. I know these can be stored in the DB, but is there any way to insert wildcards here?
Each of our customers receive their own subdomain and I would like to simplify user management by allowing all browsers attempting to access any of our apps at *.ourcompany.com to be treated as the same client in the identity server. Is this possible.
You can implement your own redirect URI validator. But for security reasons, this is not recommended as it expands the attack surface.
Redirect Uri Validator Interface
How to register your custom validator
Discussion about redirect uri
Identity Server4
I think you can add AddCustomAuthorizeRequestValidator in the startup. Still, it is not recommended to modify the redirect URI validation.
Add Custom services
Related Discussion
For IdentityServer4, you can implement your own IRedirectUriValidator and register it using the AddRedirectUriValidator extension method in Startup.cs.
services.AddIdentityServer(options =>
{
// ...
})
.AddRedirectUriValidator<CustomRedirectUriValidator>();
By default, the StrictRedirectUriValidator is registered but can be overridden by calling .AddRedirectUriValidator as shown above.