This might seem like a strange question, but is it possible to detect and reject requests sent to my web server from outside my UI? For example if someone sent a post request to create a resource using the correct authorization token or session info from a tool such as Postman, could it be detected?
I want to prevent someone from using my application as some makeshift API.
Probably the best you can do is to just make sure (or come close to that) it's a human being by using a captcha service such as reCaptcha
Related
I have written a multiplayer game using Libgdx and I would like to add a facebook login option. On the server side, I am using NodeJS and PassportJS to validate requests. So far I am able to send and receive HTTP requests using Libgdx's HttpRequest and HttpResponseListener.
My question is, is Libgdx able to display an http response in a way that a browser would? If not, I don't see how user will be able to confirm facebook permissions since I cannot show them the response they get from the facebook. I would greatly appreciate if someone can tell me how this would work. (As far as I know, nodejs redirects user to a facebook page, so I will be getting an http content to my code in Libgdx)
Note: I aim to use the application both in ios android and desktop.
First of all, for the lack of words, I used "normal web page" on the title. Please let me explain that:
Recently, I have seen many websites such as shopify.com making the most out of the modern browsers support for html5 push-state and Ajax. Instead of submitting forms, requesting new pages I see them doing all that via their REST APIs. It seems to me like a very neat way to do things because it's faster (less page reload), and also allow greatly allows us to re-use the API code.
In these scenarios, the users access the service via the websites as they would normally do, however their interaction with the resources are powered by the REST APIs.
As I dive more into the documents, it seems like these API requests should be stateless yet should always have a mechanism to authorize/authenticate each request so I looked into OAuth2 for that purpose (Since I will need OAuth2 anyhow, to grant accesses to 3rd parties). Now, since in this particular circumstance the user's browser will act as the client to request the resources via REST, I want to know what is the recommended flow to do it.
Right now I plan to implement it as followed: (I'm using Symfony 2 with FOSRestBundle and FOSAuthServerBundle)
User should login via the web form as normal (Since we need to authenticate/authorize both for the normal web page as well as for the API Requests)
When the user logged in, immediately check if an OAuth client is already created for this user? If not then create it with GRANT_TYPE_IMPLICIT. If the client is already there, just retrieve it.
Proceed to normal OAuth authorize for Rest requests?
Edit 1:
Further research makes me think that I should not send back the refresh token to the JS app as this would be too dangerous if the browser is compromised. Perhaps I could store the refresh token for the user somewhere in the server backend once he/she is logged in, then can reserve a special link for the JS app to request for new access token when old one expires? This seems a bit messy to me tho.
I am trying to implement user authentication process, and I have gone through enormous number of posts and totally agree that using HTTPS is probably best way to transfer username/password from client to server befor hashing.
Just out of curiosity, I want to know : how safe it is to send username/password from client to server using POST method along with enctype='application/x-www-form-urlencoded' as this also send form data in encoded form?
PS. I am using GWT for frontend and JAVA for backend.
Sending data by way of the body instead of url params is the way to go, but to ensure that is not sniffed out, you must use HTTPS. Otherwise it will be plaintext.
As to how safe? see here: https://security.stackexchange.com/questions/53596/how-safe-is-ssl
I'm writing a web application (that is not to be published by Intuit on their App Center thing) to interact with QuickBooks Online (QBO) for syncing purposes, using VB.NET and ASP.NET. I'm having a hard time understanding how to do this exactly or where to start. What I understand this this:
User accesses your web application and the "Connect to QuickBooks" button (that Intuit requires for In-App authorization) is displayed.
Before the button is clicked you send a HTTP request to get OAuth request credentials using your consumer credentials.
Once the user clicks the button they get redirected to QuickBooks Online (QBO) where they can sign in and then authorize access to a certain company, giving you authorized request credentials.
QBO then redirects back to your site indicating you have authorized request credentials in which you send a HTTP request to get access credentials.
Once you have the access credentials you are basically free to interact with the QBO V3 API.
Using the access credentials you can then construct HTTP requests that send a particular HTTP method with XML/JSON in the body to perform a corresponding CRUD operation in QBO and QBO sends a response to indicate whether it was successful or not.
When your application is done interacting with QBO you simply make sure the access credentials are stored somewhere safe and let the user continue on with their life.
(Side Question: Is this correct or did I miss something or misunderstand something?)
My main question: Do you, as the app developer, even need to construct these HTTP requests or do you use their SDK or something completely different and I'm just not getting it?
I've tried to figure this out but it sounds like you're supposed to construct this all from scratch but then I look in their SDK and they have classes for all the different entity types but then their serializer doesn't serialize correctly and they talk about their DataService class and how you use that to send objects over and using some JavaScript files they host that I have only seen referenced but not explained by them, or anyone really, and information I do find seems to be outdated/deprecated and ya...
Maybe it's just that I'm new to web development and all this is way over my head right now, which very well could be.
(Off-topic-sorta: Is it me or is their site ridiculously broken? It just seems like a lot doesn't work correctly or things are just hard to navigate and find...)
Anyways, thanks for any help anyone can offer. If I need to give more details or ask a different question or something, just let me know. New to this and it's harder than I thought to ask things haha.
My main question: Do you, as the app developer, even need to construct
these HTTP requests or do you use their SDK or something completely
different and I'm just not getting it?
This is entirely up to you, the developer.
If you want to roll your own and construct your own HTTP requests, you certainly can. You almost certainly will still want to use a pre-packaged OAuth library, as OAuth is not trivial to implement.
However, you could also certainly use an existing code library/DevKit too, in which case the library/DevKit will construct the HTTP requests for you.
The DevKits should contain example code to show you how to actually do this stuff, so that might be your best place to start.
You are on right track.
First of all you need to register with IPP to get
ConsumerKey,ConsumerKey secret and Application ID.
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app/implement_oauth_in_your_app
if user don't have access token then 'connect to quickbooks' button shows up otherwise you can make it hidden.
request code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthGrant.aspx.cs
access code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthHandler.aspx.cs
After getting accesstoken, accesskey secret and realmID (companyid) save that to your database.
make sure to encrypt.
so next time same user connect to quickbooks they don't need to go through all of the above steps.
OAuthRequestValidator oauthValidator = new OAuthRequestValidator(accessToken, accessTokenSecret, consumerKey, consumerSecret);
ServiceContext context = new ServiceContext (appToken, companyID, IntuitServicesType.QBO, oauthValidator);
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits/0150_ipp_.net_devkit_3.0/0002_synchronous_calls/0001_data_service_apis
As the title says,I want to build a App that run in browser with a Single Html page.but how to implement the Authentication.and my solution is:
the server-side is all the RESTful APIs,which can used by multiple Platform,web ,mobile side ,etc.and every API that need auth will be get a token to parse,if the API does not get a token return 401.
cuz my first practise is in the browser,so I need to request for the token to get login,and when the app needs to request the auth-APIs,I will put the token in the header for requesting...
and my questions is : does it safe enough? any other better solution?
No it's not safe enough if the token is accessible through javascript for the same reason that you should set your cookies to http only and restrict to ssl.
If a hacker can inject javascript into your app, it can steal the token and use it from their machine.
For that reason I suggest you use a secure, http only cookie instead of the token when using a website.
If your API is going to be accessed from a native mobile app then you could add a token to each url.
Having a custom header in the http request might cause issues with certain proxies which might not pass all headers through.
A cookie is nothing more than a standardised http header so you might as well reuse that.
What you could also consider using is OAuth if you're going to allow 3rd party apps access to parts of your API.
There is no reason why you could not use cookies for browser based clients and an ApiKey query parameter for other clients.