How to learn about web communcation standards (xauth rest soap oauth json)? - json

I am an android application developer (trying to be one) and I want to learn how to communicate with web sites from my applications. However, I don't know where to start. Can you point me in the right direction?
PS : I believe "web communcation standarts" is wrong term but i don't know how to call them.

I'd suggest that you learn by doing. Pick an idea - let's say you want to upload a picture from your Android phone to facebook.
Now go and research how to do that. Facebook exposes what they call the "Graph API" for all fb resources, including users, statuses, and photos, among other things. The Graph API is a REST API - in other words each item on the backend is modelled as a "resource" which is accessible from a URL. (Learn more about REST on wikipedia). Send a GET HTTP message to the given URL and you can get information on the resource. Send a POST to the container of that resource, and you can add another of whatever it is. In this model, to add a photo, you POST to the album URL. Read on FB for how to do that. They call it "publishing".
But reading that doc page you learn that in order to POST you need an authorization token.
Your app needs publish_stream permissions. How do you get that? Keep reading in the FB doc and you'll see a link to the Authentication and authorization guide. That tells you about how to use OAuth 2.0 in Facebook apps.
Your app will send its first feeble message out, and get an error response. Why? You'll want to examine the message. so you google and figure out that you can use an http debugging proxy to help you, something like Fiddler2 for Windows, or Charles for other systems. So you download that, set the proxy on your Android device, and now you can view outgoing HTTP messages and their responses on your PC.
Keep plugging along, learning what you need to accomplish the task in front of you: in this example, posting a photo from an android device to Facebook.
After you reach that goal, you will have learned quite a bit of practical knowledge for this domain of problem. Then you can try a new goal, and work on that.
After a few iterations of this, you will have learned how to learn, which is even better than learning REST or OAuth. If you know how to learn, the sky's the limnit.

Learn about HTTP first. There is far more to HTTP than there first appears. It is a building block for everything on the web.
You will not go wrong by getting very familiar with this http://www.w3.org/Protocols/rfc2616/rfc2616.html

Related

Looking up values in html in background of iOS app

I'm new to iOS development and I'm trying to make an app that tracks my student loans. I would like to have the app simply display a balance found on the loan's website and build on that behavior. I've got my app to open up safari to the website but I'd like more of a web-crawling behavior so it's done in the background. This web-crawler needs to be able to login to the website and then find a field with the loan balance value..
I've looked up several ways on how to do this but I can't get any of them to work with my novice level of experience with swift. If anyone has a recommendation and a direction to go with this, that would be great.
Thanks in advance!
I've written an app to get my uni's schedules, payment records, and grades by bypassing the login and gain access to API used by the website.
The step you could take are probably very similar to mine
Find out how the website authenticate its users (could be by cookie, session id's etc) You need to have some knowledge on web too. You can use the network tab on Chrome/Brave/Safari or any other browser to see what the website is doing when you click on 'login' for example. You could use Charles too, 30 days of trial should be enough.
After authentication succeed, track what API route the website use to get the datas to html. See what information you need to access the API route. Postman would be very handy to see the JSON response by the API.
To parse the response, you can use URLSession or networking library like Alamofire to get the job done.
If you want to see how I did it, here's the GitHub repo.

authentication from mobile to backend django

Good day everyone. I am stumped at the moment and would appreciate some guidance. I feel like I am a great googler to usually find my answers or resources but for the life of me I can't seem to find any good learning material on JSON requests and responses.
So I took a course that builds a 3 part app. Web app with Django, and 2 mobile apps that make API calls to it. The instructor uses Facebook authentication from the mobile apps and I am trying to set up the apps for username and login and a registration page as well.
I have django models setup and and can make users from the web app but I can't seem to wrap my head around how to make JSON calls from app to Django. When I search for possible terms like authenticate django I get results that talk about only django usage.
Does anyone have some tips or links to resources that would help me understand the login process better. I realize that almost every app has a login which is why I'm surprised that I can't find any good learning material on how its done. Or I'm just searching for wrong keywords.
Any help would be great thanks.
It's really a general question, But i give you a brief on how mobile and django server should interact with each other:
First of all, in your situation I really suggest to use django rest framework, Because of it's rich modules and functionallity like serializers, routers and ...
read more about it from origin documentation here.
For authentication system, You should use a token based system (or session). I suggest use one of django suggested token based solutions for that. In my case i really suggest to use django-restframework-jwt library
(JSON Web Token Authentication support for Django REST Framework).
so whenever you want to send a request to mobile you should provide that token (based on token authentication backend you choose) in your headers of request.
And for login and register you should create APIViews that takes user input, then register or authenticated it with backend and then gives user the generated token for future requests.
And for social auth system like facebook, the main concept is to redirect user from app to facebook oauth links, which if the user authenticate in his facebook will redirect you redirect url of your backend server, then you should capture that request in callback, fetch data and create or get the user and generate the token for that user and return it. so that for furture requests, by sending token to server, server will know that which user is sending this request and handle response properly for that.
And if you want to create a login with mobile, then you need to setup APIs for login, register with django rest which is really easy and you can learn from it here.

Facebook login broken, oauth response serialization changed from CGI parameters to JSON

Today the Facebook oauth login to my website broke. I fired up the debugger and found that parsing the access token was failing. This appears to be because Facebook changed the format of the oauth response. It used to be CGI parameters:
access_token=EAAFO...cBUZD&token_type=bearer&expires_in=5183996
But all of a sudden it appears to be coming over as JSON:
{"access_token":"EAAFO...cBUZD","token_type":"bearer","expires_in":5183996}
The fix in my code looks pretty simple. I just need to change the parser from a CGI parser to a JSON parser and get the same variable that I'm interested in: access_token.
My question is about versioning of this. I don't like it when my site breaks.
Why did Facebook change this? Is this change documented? Is there some sort of versioning on Oauth that I should be using to prevent breakages like this? How do I get notified of future changes to Oauth by Facebook?
The Facebook API upgrade tool does not list any changes that I need to my app for the latest version of the API. In any case, none of the URLs that I'm using for Oauth appear to have a version number embedded in them:
https://www.facebook.com/dialog/oauth
https://graph.facebook.com/oauth/access_token
As WizKid states, it was announced in Facebook Developers Changelog two years ago under the title "[Oauth Access Token] Format". Facebook does have a tool to try to find things that will break, because of API changes, but it didn't alert this one.
You can put API version numbers into Oauth URLs for Facebook. With version numbers, the flow for Facebook login is:
Redirect the user to https://www.facebook.com/v2.9/dialog/oauth with a bunch of required parameters such as your client id, the list of permissions you are requesting, and a return URL.
Facebook lets the user log in, asks them to accept the permissions you requested, and then redirects them back to your site with a "code" parameter
Server-side you contact https://graph.facebook.com/v2.9/oauth/access_token with that code (and some other stuff) as parameters. Facebook responds with a token
Server-side you contact https:///graph.facebook.com/v2.9/me with that token to request information about the user
This is the process that is pretty much documented here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow

Node.js security

I am building a basic app using node.js and mysql and just getting a hang of it, I would like to secure the api,like only allow certain people to access the data, maybe by passing a certain token each time a user requests for some information, I tried searching for certain tutorials which used node.js and mysql database and security, I am confused as to which security measure to use, I even read about Json Web Tokens but din't find a proper tutorial for that.Please point me in the right direction.
EDIT
What I meant to say was, only authenticated users are allowed to get access to data in the api, when a random visitor tries to access a URL he shouldnt be alowed to without proper authentication,what I am mostly looking for now is when a user is authenticated the user should be a sent a token of some sort so then gets access to private data,I don't exactly know how to go about this whole thing.Would be glad if you could clear it up for me.
I would look at implementing Oauth2 server in your app. I found this article useful:
http://blog.papersapp.com/oauth-server-in-node-js/
No sure what your exact question is about, but I think the below will help:
Node.js security tips: http://blog.risingstack.com/node-js-security-tips/
Secure Express apps with various HTTP headers: https://github.com/helmetjs/helmet
Go on an educational Web security adventure: https://github.com/toolness/security-adventure
Node.js Security presentation: http://www.slideshare.net/d0cent/nodejs-security?qid=c450507b-e491-4e9a-9b05-89d0c82ea10b&v=default&b=&from_search=6
Take a look at http://passportjs.org/ . Passport has support for alot of authentication methods, however, for your API, you will probably want to use OAuth (http://passportjs.org/docs/oauth2-api). OAuth is what most popular APIs use to authenticate consumers.
For simple projects, You can also use basic authentication, which is what you see when you see the browser prompt asking for username and password. This authentication information can be sent in the header when API consumers makes requests.

Is there a generally available HTTPS POST smoke test?

When debugging an HTTP client, one of your first tests is likely to be a Google search, which lets you see whether your client does non-SSL GETs properly. Everyone knows where it is, everyone can use it, and everyone can see whether it succeeded.
My client has a problem with HTTPS POST. I can reproduce it locally with my specially set-up HTTPS server, but I want others to be able to try it as well. Is there a public web page using HTTPS where sending a test POST is not a bad idea?
Edit: In the end, the problem turned out to be that my client would cache network output by the line when sending over TLS. Obviously, that causes problems for POST but not for GET...
I stumbled across this question while looking for the same thing, but I also found https://posttestserver.com/, which provides such a service for HTTP and HTTPS.
Google App Engine has supported HTTPS for a while now. That should give you a simple, easy way to put up test pages for anybody to see and serve them up over HTTP and HTTPS. Give us the link too, could be useful to use for our clients if the tests are generic enough.
The simplest public HTTPS post test I can think of would be webmail.
For example create a dummy Google account, then take the username and password of that dummy and see if the user can login using https://www.google.com/accounts/ManageAccount (a simple HTTPS post form).
Create a twitter account. Because of the json api, checking for a valid post to twitter is very simple. For the POST, you can look at the API docs for Status Updates. Once you've made a post, you can check the results at the User Timeline.
The API docs even have simple examples with curl to show you how easy it is. The POST:
curl -u user:password -d "status=testing my HTTP POST request" https://twitter.com/statuses/update.json
And getting the status to check it:
curl https://twitter.com/statuses/user_timeline.json?screen_name=user
Any login form should do.
In short, no. But without further info as to what specific bug you're experiencing, it's hard to search for something that already exists. My suggestion would be to find a free hosting service, and put the test page up there, along with a small google ad for some revenue.
Interesting concept, though, the publicly available test cases for standards. I like.
I'll bet that google search will accept a search paramter as POST if you sent it that way.
SSL adds a lot of complexity to the transaction, and you actually should break it up into two pieces.
You should do an GET w/ HTTPS first. When I was smoke testing networking for Netscape/AOL/Mozilla, I used http://www.verisign.com, because that was the home page for the main certificate vendor. I did not test the HTTP/SSL implementation itself, but we figured that while we are sitting around clicking on links in a build, we may as well do some SSL versions of the HTTP requests.
I cannot easily think of a good https: URL that uses POST, but I actually think it matters a lot less.
Once you know that SSL is working w/ HTTP at all, failures that are request-specific are going to be pretty limited, based on my recollection. Then again, this area was not assigned directly to me, so take that with a grain of salt.
My more recent thinking about testing is that test groups need to setup their systems, especially test servers. You would probably get better mileage by getting a good working set of instructions on how to configure HTTPS w/ a self signed certs, and then create your own internal POST test pages.