I have an API in Laravel that only consume in my frontend. The problem that arises for me is how to authorize the use of the API to a single application without revealing information that other applications may apply to make use of it (an example of this would be sending a header, which can be obtained and replicated).
I understand that with Passport I can get it but it seems to me to be a very sophisticated solution for a case where I will only need an authorization and I would just like to know where to look since I can't find anything. Sorry for my bad English.
Related
in my Laravel 5.7/mysql app I need to make external api to read some data from external
app with get request and to write some data to my db with post request.
Which tools/scripts are there for this and how to make these requests safe?
MODIFIED :
Thanks for feedbacks, but looks like I badly put my question
The external app(I do not know what is it written with) need to read data from my app
and write data to my Laravel 5 app.
And how have I to test these requests while on development locally ?
Looks like I have to use Guzzle as in provided link?
Which steps have I to take for safety on my side?
Thanks!
These three libraries are popular for your use-case:
Guzzle
Curl
zttp
If the database is local you can use Eloquent, If not, remote connection to that database may help. otherwise, if you only have API access you should consume eighter of above libraries or any alternative options to make an HTTP request your application might require.
Security-wise, as long as you are only making a request to a remote server, the Suggested way is to store any key or secret string related to authorizing your request (if applicable) in your .env to prevent it from committed to your version control systems. Needless to say to always handle any possible HTTP error your remote API might throw in order to prevent any unwanted error on your application side.
And as Abir Adak mentioned in the comment check this thread for further details.
Updated Answer: On the case of MODIFIED part, generally you have 3 popular options,
REST API
This blog post is a detailed walkthrough written for Laravel
This one from Stack Overflow can help you with designing you API
This last one can help you to develop a widely accepted API response and endpoints by following its specifications.
GraphQL
Can save some time for developing your API, but I suggest to make sure that the consumers of your API are happy to use this option.
GraphQ
Laravel Package for GraphQL
If using Laravel isn't a must, and you are using PostgreSQL, you might want to look at Hasura as well.
SOAP
Have little knowledge on this option for Laravel, just know folks coding using C# and .net are happier to expose their API with this protocol. read more about it on WikiPedia
Postman is a great tool for testing your API or any other API.
We are using BotFramework Composer to create bots. These bots are supposed to get information from a backend REST service, where we need to know, which user is submitting the request for data. We are currently using {turn.activity.from.id} to get the Teams user's id, and sending it in a special http header in the "Send an HTTP request" action. We then perform a mapping of this id to our internal users.
We are, of course, aware, that this is not secure at all, since anyone who knows this, could get the user's id and send it to our service. We are currently thinking along the lines of generating a short-lived jwt token in the Bot to send to our application. However, we see no direct way of implementing this token generation in the Bot Framework Composer itself.
Also, we don't want to use OAuth, because we don't want the user to have to log in via the bot.
Is there a way to implement custom token generation using C# or js and assigning it to a dialog variable to be used in a "Send an HTTP request" action?
This document discusses how to implement an HTTP request in Composer. The first half is focused on creating a login for OAuth, which I know is not your focus, so look at the second half. If you set up a simple server that can generate a token for you, then you can make a request to it from Composer using the method described.
As links can break and docs can change (and Composer is still in Preview), I would recommend saving the doc somewhere and checking back every so often for any updates.
I've used HTTP requests from within Composer, myself, so I know this will work for you.
Hope of help!
You can create a custom Action or a package component and create any c# methods there for JWT generation. This will keep it all local to the bot.
https://learn.microsoft.com/en-us/composer/how-to-create-custom-actions
I'm doing OAuth2 to integrate Square and my app which uses Parse as its backend.
My issue is that when Square calls the redirect uri, it directs the user to a subdomain I created in Parse with the authorization code appended to the subdomain uri. I need to extract this authorization code from the uri, but do not know how. Parse Cloud Code is needed to do this.
I believe I need to create a Webhook URL in Cloud Code and then extract the data appended to the URL, the base of which is the subdomain URL. Steps outlining the process, code examples and links to helpful documentation would be much appreciated.
Furthermore, once I figure this out, I need to have my web browser jump the user back to the app that brought up Square initially once this redirect URL is called. Not sure how to do this and haven't found things that make sense. Tips, recommendations and links would be appreciated!
Thanks!
I think the best way to go would be create an independent route on the server that handles all your communication with square. I mean something that doesn't have Parse.
You can now still communicate with Parse from this route and make queries but the best thing is to just create a separate route that id devoid of parse.
Because even if you can find a way to implement via triggers or hooks, Parse might not be able to give you a flexible implementation that can be extensible over time.
I am in the middle of building a PhoneGap (Cordova) app which I would like to be able to talk to a Django site of mine. The steps needed to get the app working are:
Authenticate the user (stay logged-in across app restarts) (e.g. get session cookie from Django for communication with the service - where to store?). Note: The Django endpoint uses https.
When app receives push notification load some data from my django site.
Make selection on data and submit response back to my django site (will need the csrf token?)
I was able to sort out the push notifications but now I am wondering which solution would work best for the communication with Django.
As I understand there are two possible approaches:
Either to implement a REST service with something like tastypie or
try to setup the communication via ajax (e.g. jQuery)
At the moment I am thinking that going simply ajax might be the best approach since the app is fairly small and there are no additional requirement for a REST API.
It would be great if anyone could give me any pointers on how to solve this or share some experiece / code. Especially the steps of the authentication process are unclear to me.
I am not sure if this is still an open question but it is sure an interesting one.
I would strongly suggest on using the django-tastypie and you could start by using the docs which are indeed a great point of reference.
My experience until now has shown that I should always start by making my api clear(and rest) than choosing an easier faster solution(e.g. ajax) because if your app is a successful one, frameworks like tastypie help you scale.
The authentication process is pretty straightforward if you choose the basic one.
You just ask for the user credentials and there are many clients implementing the client side basic auth.
Fortunately, tastypie supports more than this. For example, the api authentication and you could read more here.
If you need anything else, please let me know.
Regards,
Michael.
I am creating a web service which uses REST web services. The client side code is written in HTML/JavaScript. My dilemma is whether I
should use the REST resource directly using AJAX calls?
or
should I create Servlets/JSPs (where REST calls will be made and data will be sent to client(AJAX/JAVSCRIPT)).
I have seen many web apps which follow the 2nd procedure but seems to me that it's doing the same thing as 1st in an indirect way.
Is there any advantage of using 2nd procedure over first?
What is the standard way to use REST services by HTML/javaScript client?
Please let me know if I am even thinking in the right direction and if not please give your valuable insight.
You can use either approach but note that browsers will enforce the same-origin policy on scripts, so if the REST service lives on a different domain than the script you will need to use a servlet/script on the same domain as the script to proxy the call to the other domain. I suspect this is why you are seeing the second approach used.
A proxy/middle-man servlet may also be useful if not all of the response is needed; you could use the servlet to strip out information that is not needed by the JavaScript to reduce the amount of data sent to the browser.
Directly accessing the resource(s) via AJAX has the obvious benefit of less overhead and is IMHO the more elegant solution, however it is also important to note that not all browsers support PUT and DELETE requests natively.
To get around this, you'll likely want to support the common "_method" hack. This stackoverflow question mentions this approach.