1

I made an android application for the creation of personal timetables. I need two things for the user interface: The grades list and the student lists of the senior grades. To retrieve those, I made a java websocket from which I can get the list. Since I don't want everyone to get the student lists from my server, I secured the connection (using a self signed certificate). Now I'm building a ui for this, similar to the ui on android.

My problem is: How can I securely get the student lists?

I know that I can't connect to a normal server socket in javascript. Sorry if the answer is obvious, but that's the first time I'm developing a web application. I just don't know how to start off, I haven't found anything on the internet.

Improve this question
5
  • 1
    Can you clarify why you cannot connect to a normal server socket in javascript? Can't your page's javascript do an HTTP request (possibly an AJAX call) or open a websocket (I'm aware that websockets are not fully supported on all browsers)? Or do you mean that open a normal server socket is not secure and therefore cannot be used? If that is your question you might look at stackoverflow.com/q/6969316/814206 and stackoverflow.com/q/30902547/814206 to find some answers?
    – Kasper van den Berg
    Oct 17, 2015 at 14:46
  • What I mean is that when I connect, the javascript just sends a normal GET request to that server. I can't just open the connection (which sends nothing) and then send my own command on which the server reacts with sending the requested data. Can I find somewhere how to answer on the GET request so the websocket.onopen function fires? I think I need some understanding how websockets in javascript work.
    – guest
    Oct 17, 2015 at 15:46
  • You might be interested in some of the guidelines here - in particular the "Authentication/authorization" section might be of interest. Also, for a specific authentication scheme, you may be interested in something like OAuth if you haven't checked it out yet.
    – J Trana
    Oct 18, 2015 at 3:01
  • 1
    When you say you "secured the connection using a self-signed certificate" do you mean you require the client to connect using one? Or that the server uses one? In either case, you are aware that this doesn't prevent anyone downloading your data, right?
    – Jules
    Oct 18, 2015 at 3:14
  • @Jules I created a self signed certificate and a client trust store containing the server key. I set up the server to refuse any connections not connecting with this key. Do you mean one could connect using any self signed certificate? Explain please why anyone could retrieve this data.
    – guest
    Oct 18, 2015 at 10:07

1 Answer 1

Reset to default
1

Connecting

As for connecting from JavaScript, you can make HTTP(S) requests using normal client tools, either an XHR in plain JavaScript, or using framework objects like jQuery.ajax() from jQuery or $http from Angular. WebSockets are also available from supporting browsers. Here is a tutorial on how to get started with that.

Security

I want to address 3 separate security layers here.

First there is connection-level security. This answers the question: Can someone other than the client and the server see the data transmitted. Using HTTP, any device that can see your traffic (other wifi users, routers between client and server) can intercept the data and read it because it is plain text. HTTPS helps address this concern by encrypting the data so that even though it can be intercepted, it can't be understood (practically speaking). Also, HTTPS is still not considered secure unless you get a signed certificate. A signed cert is essentially being vouched-for by a trusted authority.

Second, there is Authentication. Can a particular client access my application? Having only HTTPS, any client (e.g. browser navigating to URL) can still access the data. You have to add an authentication (login) to your application so that you can tie that particular client to a valid user of the system. Common today is token-based authentication where you issue a token when the user successfully authenticates. Then the token is sent with each request to identify the user. To be secure, this requires HTTPS. Otherwise, the token can be read, copied, and used by any listener. Search terms here are OAuth, bearer token.

Third, there is Authorization. Having only Authentication, you can say it's a valid user of the system, but you still cannot say what that user is able to do in the system. If all users are capable of the same actions, then Authentication is enough. However, if some users have different operations available from others, then you also need Authorization to instruct your server what the user is allowed (authorized) to do. The common way to do this is either by Roles or Claims. When the user is authenticated, often the user's authorization (role or list of claims) is also loaded into memory. Subsequent requests with the same token can look up the user's authorizations to decide whether or not they can perform the given operation in the system. Search terms here are Role-based or Claims-based authorization.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.