I have few basic questions on session management in GWTP.
Client : GWTP, Server - Restful WebServices using Guice and Jersey.
Application session management is straightforward when i have the backend service with RPC mechanism. But, With GWT client running on android and server side logic exposed as Restful Web services using Jersey, how do we maintain session because Restful WS are stateless. Now how do we achieve user session in this case?
Regarding session management there is no difference whether you use GWT's RPC, RequestFactory or RequestBuilder.
Communication in the web is basically stateless regardless of the communication protocol you are using.
Traditionally session management is done via server side sessions.
However RESTfull services are not supposed to rely on server side sessions as it violates restful principle.
So basically there are two ways to do it:
If you don't care much about violating the restful principles you can deploy server side sessions (see here for more details).
use OAuth (https://wikis.oracle.com/display/Jersey/OAuth)
somehow pass the credentials/securityToken for every request to your backend. You can probably do that by using GWTP's ClientActionHandlers.
After going throught lot of comments from different people, here what I have thought of doing.
My application can be accessed from Browser based app and Mobile devices as well. Application was written the http session management in server at first for browser based app. Now while getting Mobile client, we have implemented Rest web services, with same service layer for mobile device and browser client as well.
When user logs in with mobile device, we are creating a unique auth token and we store the http session with this token ID as key, value map in app. Later on we expect every user request from mobile device to return this token, and using this token get the session from map and continue.
Does anybody has any opinion on this approach?
Related
I am developing a web application with Spring Boot and a React.js SPA, but my question is not specific to those libraries/frameworks, as i assume reporting client-side JS errors to the server (for logging and analyzing) must be a common operation for many modern web applications.
So, suppose we have a JS client application that catches an error and a REST endpoint /errors that takes a JSON object holding the relevant information about what happened. The client app sends the data to the server, it gets stored in a database (or whatever) and everyone's happy, right?
Now I am not, really. Because now I have an open (as in allowing unauthenticated create/write operations) API endpoint everyone with just a little knowledge could easily spam.
I might validate the structure of JSON data the endpoint accepts, but that doesn't really solve the problem.
In questions like "Open REST API attached to a database- what stops a bad actor spamming my db?" or "Secure Rest-Service before user authentification", there are suggestions such as:
access quotas (but I don't want to save IPs or anything to identify clients)
Captchas (useless for error reporting, obviously)
e-mail verification (same, just imagine that)
So my questions are:
Is there an elegant, commonly used strategy to secure such an endpoint?
Would a lightweight solution like validating the structure of the data be enough in practice?
Is all this even necessary? After all I won't advertise my error handling API endpoint with a banner in the app...
I’ve seen it done three different ways…
Assuming you are using OAuth 2 to secure your API. Stand up two
error endpoints.
For a logged in user, if an errors occurs you would
hit the /error endpoint, and would authenticate using the existing
user auth token.
For a visitor, you can expose a /clientError (or
named in a way that makes sense to you) endpoint that takes the
client_credentials token for the client app.
Secure the /error endpoint using an api key that would be scope for
access to the error endpoint only.
This key would be specific to the
client and would be pass in the header.
Use a 3rd party tool such as Raygun.io, or any APM tool, such as New Relic.
I currently have:
a REST API (Jersey) that runs as a seperate application
a GUI application (JSF) that is a client of the REST API
I'm wondering what the best way is to talk to the REST API from the GUI application. The REST API is stateless, but the GUI application is stateful and has to pass authentication info (basic auth) with every rest request. Because we have to support hundreds of simultaneous users, we want to configure our Jersey client for connection pooling.
We can handle connection pooling by configuring the Jersey client with Apache's HTTP client. Authentication can be handled by using the HTTPBasicAuthFilter, which will automatically send the same credentials with every request.
However, I'm not sure if it is best to configure 1 client for the entire GUI application, or to create a new client per session.
With 1 client for the application, connection pooling makes sense, but then I have to find a way to set the correct authentication info on every request. The HTTPBasicAuthFilter assumes that the credentials never change, which is not the case our app.
If I create a client with a new HTTPBasicAuthFilter per session, then authentication is trivial, but I don't get any benefit from connection pooling, since every client will have its own pool.
I doubt I'm the first one to run into this, so I am curious how other people have solved this.
Kind regards,
Glenn
You can attach client filters at the WebResource level. So you can have a single shared client and per-session WebResource objects that you attach the HTTPBasicAuthFilter to.
I have a COTS application(PLM application) which has provided few SOAP APIs to access. Since this SOAP API is highly complex, we are developing a easy to use REST wrapper service. Before invoking any API in my COTS application, authentication API needs to be invoked. In my REST wrapper web service, I have a login resource which invokes COTS SOAP login API. To keep things simple for my API users, I store the logged in user details in user session. In every other REST resoruces, I retrieve the session and check whether session has user details. If yes, I proceed and invoke the SOAP API. if not, I return proper HTTP status code. I use Apache CXF for service and client. I mandate my APIusers to maintain the session in the client like this
WebClient.getConfig(client).getRequestContext().put(Message.MAINTAIN_SESSION,
Boolean.TRUE);
In every REST tutorials, it said REST is stateless. I am doubtful whether what I am doing is correct as per REST standards. Please suggest. Thanks
Basically the idea of REST is a stateless interface. However it is common practice to use some kind of authentication for API calls since most of the time not all resources should be public (e.g. the timeline of a twitter user over the twitter API)
Therefore it is ok if you do some kind of authentication and validate a session on further requests (or maybe authenticate with every single request, e.g. with HTTP Basic Access Authentication) to check if access should be granted.
Not part of this and not the idea of a RESTful API would be to store complex session information that would really make the whole thing stateful. This for example includes storage of information of an older request for processing together with one following later.
client.getRequestContext().put(Message.MAINTAIN_SESSION, Boolean.TRUE)
This code causes cookies to be maintained in that specific client only.
If you want those cookies be available in another client, it needs to be programmed.
And if the second client receives additional cookies and you want those cookies available in the first client too, how is that possible?
I need something like a root client that maintains cookies of all sub clients. All cookies must be shared among all clients. Like a shared cookie repository for all clients. Does anyone know how to achieve this?
Regardless of whether I create a RESTful Web service to be consumed by Ajax in my own pages, or by any user, I can provide the same functionality (data) to the application or user using a simple servlet.
I mean the user or application don't see any different between response provided by a simple servlet or respone provided by a RESTful web service. So, I'm guessing that the benefit is on the server side and to the developers. Can someone please tell me what are the benefits of using RESTful web services.
I appreciate any respone
By definition a webservice is intended to be consumed by any client granted access. If the client you are developing is the only application that you will ever need or want to access the resource then there is little benefit to creating a webservice. However, if you want to make the resource available as a service endpoint for more than just this application in a way that is implementation agnostic then a Restful webservice is a great way of doing it.
what are web services(Rmi,ejb,soap)? what is the difference between web services and web application? Is it possible to implement web services in web application?
A web service is a way to transmit/expose information in such a way that a Web Service client, which can created in a server script or from a stand-alone program, can call the service for what it wants using methods and functions defined by the service.
One of the benefits of a web service is that it abstracts these methods and functions (and variable types) in such a way that any language that "speaks" web services can use it's own syntax to interface with the service (thus making it cross-language).
Another benefit is that it uses the HTTP protocol (usually transmitting via XML or JSON, but not necessarily either), so it's also cross-platform.
A huge benefit is that an application that typically requires very specific knowledge and software can "expose" information via a web-service. So if you're corporate mainframe has tons of top-secret data that typically requires a terminal client, etc, to get data, certain data can be accessed via a Web Service so that you can have your HR department download and upload timesheet changes from a web site.
A web app can certainly include a web service, but they are not the same thing. You can make a web service using PHP or .NET, and then have a web app written in either language interface with that service, but a web app tends to be an interface for the site you're on, while a web service is about getting info to and from other apps (web or not).
web app is user interface, access by humans, user can browse data , can submit and retrieve data. All user interactivity (the GUI) is done through web pages, but all data is stored and manipulated on the server.
Web service server-based application and meant for interaction with other programs.
A web service is a way to expose some business logic you have over the internet. Say you got a module that connects to the database and does something. You can let other applications on the internet use this module of yours via web services. Web services uses SOAP over HTTP to invoke the request and retrieve the response in XML.
Web application - Person-to-server with HTTP, HTML
Web service - Server-to-server with HTTP, SOAP, XML