I'm developing a mobile application that requires users to login, and then they can use the application. The application will submit data to the server upon submission. Here's my question: if I want the application to be available to users even when there is no internet connection, I will allow them to bypass the login screen and use the application without logging in. However, once an internet connection is available, and the application knows that, and tries to submit the information to the server (through jQuery AJAX), how do I validate the request? It seems like if someone really wanted to, they could set up their own web page and submit their own [fictitious] data to my server using the same AJAX URL and data format that my application is using. What would stop them? How do I ensure on my server side (receiving end of the AJAX request) that the only data coming in belongs to my application, and not someone who is simply mimicking my AJAX requests?
The only thing I can think of is when the application detects that the internet connection is back, immediately show the user the login screen, and then use an expiring cookie/ticket to validate the AJAX requests.
Any advice? Thanks!
Related
I have implemented authentication, based on jwt tokens in my app. But I have some trouble with logout action. When I press logout, I simply clear my local storage from access_token value.
Let's imagine, that user opened three browser tabs with my app. One of them is unprotected and there is some unsaved user input (tab1). Other tabs (tab2,tab3) have protected resources. When user press logout button on tab3, I want to redirect him on login page (because he is on protected tab). Also I want to redirect him on login page when he makes tab2 active, because it also has unprotected resources. But I do not want to redirect him from tab1 (because it is unprotected), and I do not want to renew it, because user will loose his input. How can I implement this?
TL;DR: In order to achieve this, you'll need to implement WebSockets.
A standard single page application written in angular works over HTTP, which, according to wikipedia:
HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.
Request-response is one of the basic methods of communication between computers. One computer sends a request, the other one sends back a response - it's just so simple (on the surface. The underlying technology handles a lot of stuff, but it's out of the scope in this answer).
But, as with any (simple) technology, it has its constraints. A request contains information about its sender. Upon receiving a request, the server handles it and sends back a response to the entity that issued the request.
Now let's consider your scenario
You have 3 opened tabs with your app and 2 problems here:
Suppose you log out on tab 3. Because you use JWT token authentication (actually any token authentication behaves similarly), the proper log out action consists of just removing the token from your local storage in the SPA project instance on the tab 3. The application state of the project in tab 1 and 2 does not change in this case. Also, logging out doesn't require any request to the server, thus no response is send that would somehow notify of the changed authentication status of the user.
Even if you'll send a request to the server to notify it about the log out action on the tab 3, the server does not know about other 2 opened tabs, because the request holds information only about the entity that issued the request, thus it will just send a response to the third tab.
Entering WebSockets
Note: Before reading on, I want to mention that I don't have practical experience with websockets, so you can take everything I write with a grain of salt.
Again, according to wikipedia (highlights are mine):
The WebSocket protocol makes more interaction between a browser and a website possible, facilitating the real-time data transfer from and to the server. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server.
WebSockets provides a full-duplex communication channel, meaning that the server doesn't only provide responses to client's request, but also initiate data transmission. This solves the second problem mentioned above leaving you the task to solve the first problem - notifying the server about the logging out of the user. Once the server knows that the user has logged out, it communicates this fact to all other clients, thus synchronizing the state of your single page application among all tabs.
Angular doesn't provide websockets support out of the box, but there are modules that give you the possibility to use them in your project. Just google it.
Hope this helps you.
I would like to know if the following is possible and if it is please guide me in the right path.
My site is x.com and when a user submits a form on my site an API call is made to y.com which returns a JS hash (yeah very outdated, I know).
You can see the call to y.com being made in FireBug with returned params. Problem is that Adblocker Plus is intercepting this content and blocking it from view. (Not good (displaying a message about ad blocker is not a solution (In this case the user is actually expecting the ad)))
Is it possible to have my server make the request to y.com server (without the user's client being aware) get the response on my server side, and then finally generate the page and with the response content in the body, and lastly render to client?
This is entirely possible. You could define an endpoint on your local rails app (x.com) and submit the form to that endpoint. Then use an HTTP library, I prefer rest-client, to then submit the form to y.com.
I am trying to handle following case, I am new to web-app world so please pardon my ignorance (if any):
Assumptions/Constraints:
I don't have any control over the web-app code base whatsoever.
Authentication is being handled at http proxy level.
Scenario:
User has authenticated with a web-app using SAML and has been accessing the web-app for quite some time.
His authentication token (or cookie) expires.
He submits a form (HTTP POST).
Server needs to perform the authentication workflow again, which requires a HTTP redirect.
Now, the requirement is to somehow resubmit the original HTTP POST, after completing the authentication workflow, automatically for the user. A couple of options I could think of are:
Use javascript injection to store the POST state in browser's sessionStorage and rePOST things after completing the auth workflow. But I couldn't figure how would this work if the original POST was done using XMLHttpRequest ???
Store POST state on server (or proxy) side and do an internal rePOST and return the result to the browser.
Are there any other options ??? It'd be great if we could avoid saving state on server side. How do people usually handle such scenarios?
TIA,
praddy
Generally the second approach is implemented.
You send the request to the server running the application, it preserves the POST data (actually the again doing the authentication does this), sends you to authenticate, redirects you back and POSTs the data again. This feature may already be present in your authentication infrastructure and just needs to be enabled, but that of course depends what you are running.
This feature is sometimes also referred to 'POST data preservation'.
I'm using VS2010,C# for developing ASP.NET. I want to send periodical messages to server in order that server knows which user is really active (with open windows), so that when a user closes window or changes url (instead of clicking on logout button), my server can detect user sign out and can close his session. what are my options here? I don't think JavaScript would be safe as I should probably update my database (is there any other way? for instance can I call an address in my JS function?)
Another solution would be to use AJAX to send server side messages to server, is it safe and efficient? what is the best way? security is really important for me
Using ajax with JQuery is a good option
I am trying to build an error reporting service for my web page. The idea is simple. If an error pops up in a client browser while visiting, I want an error handler to send me notofication about it. My page is static, so I want to avoid adding server side components for that. Can I use ajax request for example and use a gmail account to send the mail to me? I guess ajax does not do cross domain? Maybe there is some other option?
EDIT
My primary language is Java.
What about Google App engine? I can host an app there that can send email. Not sure how I can interact with that app though?
Other idea - if I must use server side component, maybe the best option is to find ready web application (I have java application server running on my host) that sends mail and deploy it. Then I can contact the mail sender with Ajax.
The best way to do this is the following:
You need to set up a web service that accepts the error information.
The web service will generate the email content and send to gmail.
The client (via ajax) will consume this web service and post the error information.
This way your credentials are secure on your server. If you indicate the development language, we may be able to help with a bit more details.
Bob
If you were to be using GMail then you would:
Be using a server side component (GMail's scripts!)
Have to expose your GMail credentials to every visitor (bad!)
Do cross domain Ajax with a third party service (which requires a pretty recent browser and the cooperation of the third party).
You need your own server side handler for this.
You can, ... theoretically. You do not want to, because you would have to send the authentication information for your e-mail account to the client.