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.
Related
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.
I'm trying to find a way to have Square not forcefully redirect my web application on a Connect payment. Right now, I've registered my url in https://connect.squareup.com/apps as https://example.com/square_callback (or whatever), and I pass along my own metadata that tell my application where to redirect back to so our users don't have to drill all the way down to where they were when they first jumped in.
So two questions.
One, is there a way to have that URI be dynamic? They're taking payments from https://example.com/customer/1351743, and that's where I want them to return to, so is there a way to have a wildcard redirect uri, something like https://example.com/customer/*?
Second, is there a way to not have the page refresh at all? These particular pages take a while to load, our users are out in the field with spotty connections, so while I want the square response to go to the server, I'd rather have their page not refresh at all. Possibly by using # in the URI?
To answer your first question, you can not register a wildcard domain or specify the the url in the request. This is mostly a security measure to prevent someone from skimming your information by hijacking your javascript. You can specify multiple urls in the developer portal and dynamically pick between them with your request.
I'm not 100% sure I understand your second question, but I'm going to interpret it as you want to switch back from the point of sale application to your webpage without "refreshing" the page. This isn't possible, since the app switch isn't as much of a switch back, as it is opening a new url. If you didn't load a new page, it wouldn't be possible to use the GET parameters that Square sends you back in the response from the transaction.
Sorry, both No :(
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 have searched the Internet, but I can't find the info I'm looking for. So I'm sorry if it's a simple question or asked a miljon times.
I'm developing a website with (probably) a lot of Ajax functions. Now I'm wondering how FaceBook is doing this, for example the 'Like' button. If I use a ajax call to a page addLike.php?post_id=1, then an visitor (with evil intentions) can use this url to manipulate my db by adding random values to the post_id.
How can I prevent this? Or what's the best way to do this?
First and foremost, calls to make mutation to data entries (something stored in the database, files, etc.) should never be accessible from a 'GET' HTTP request, e.g. deleting a post in a forum. That is to say, if you're adding like to a post, you should use $.post to perform an ajax request (supposing you're using jQuery).
And also, authentication and authorization should be done before responding to every request. Which means, if the user wanted to add like to a post, he/she should have been authenticated and also permitted to perform the specific action. Prevailing web frameworks will help you to achieve this automatically (with configurations).
And further more, you should also prevent XSS attack by data sanitization. You can google it for more details.
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.