Let's say that user session is about to expire. Before it expires I want to give an opportunity
to a user to prolong his / her session, i.e modal window asking to continue or invalidate session.
How to implement that in wicket 9?
Are there any hooks before a session is about to be invalidated?
There are no such hooks! The Servlet API does not provide such!
Even if there was such API then you have to use WebSocket connection because it is not possible to send something from the server to the browser without a http request. And a request will "touch" the http session and make it alive for another N seconds/minutes.
You have to implement this with JavaScript on the client side. Use setTimeout(showModal, N) and clearTimeout() to reset it whenever an Ajax request is being made. You can use Wicket's Ajax hooks or jQuery hooks to know when there is an Ajax request.
See https://github.com/reiern70/antilia-bits/tree/master/client-sign-out-parent for an inspiration!
Related
I'm trying to implement JWT authentication in a SvelteKit-app and I'm having trouble with where in the code I should refresh my accesstoken on site-reload.
According to what I have found I should store the JWT in memory and then have a refresh-token that is stored as a HTTP-only cookie. When the page is reloaded or opened in a new tab, I need to call my backend to see if the refresh-token is valid or not, if it is, I will generate a new JWT and return it to the client.
Where is a good idea to make this call? I was thinking that the getSession-hook would be a good place but I'm not able to use fetch from there.
HTTP-only cookies must be set via the Set-Cookie header. SvelteKit only has a few places where you can set response headers:
Svelte Endpoints
The handle() hook.
getSession() is probably not a good choice. The main purpose of this hook is create a sanitized version of the server context for the browser (like remove sensitive information like passwords/API keys.) It is called after the handle() hook, so it would be too late for setting any headers in the response.
getContext() may be a better choice because it is called before the handle() hook. So it is possible to get the refresh token and store it in the context until handle() sends it as a header. The context is accessible from handle() as request.context
Although not well-documented, fetch is available from all of these hooks. Simply add node-fetch as a dependency in package.json (not a devDependency!).
I think a problem with refreshing the token in the hooks is refreshing will happen on every request. This may add unnecessary overhead to your app.
I think the best solution is to wrap any API calls that need JWT tokens as SvelteKit endpoints. If the API call fails due to a stale token, the endpoint can get a new token and send it to the browser via Set-Cookie in the response headers. Note for this to work, you must ensure the endpoint is being called by the browser (not the server.) SvelteKit templates are executed first on the server, then again in the browser. If the endpoint is called from the server, the browser cookie will not be set.
Is there an idiomatic way to handle authorization from browser on Akka-based WebSocket endpoint? It looks like Javascript WebSocket API does not allow to send custom authorization headers which means client will probably have to send authorization token via the WebSocket once connection is established. So, what I am essentially looking for is a way to create a flow from sink and source but block it until client sends in a valid authorization message.
Another consideration is, what if authorization token expires at some later point. Supposing client refreshes its token by some external means, is it possible to, again, block the flow until client sends in the refreshed token, or kill the connection if it doesn't happen within some time frame?
This must be a reasonably common use case but for some reason I cannot see obvious way to implement it without writing tons of code. Would appreciate any suggestions.
I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).
I am creating my first webapi project using ExtJS for the client-side and trying to understand login procedures. I'm trying to understand what SESSION is used for and if I use REST, SESSION should not be part of it.
REST by design is stateless. By adding session (or anything else of that kind) you are making it stateful and defeating any purpose of having a RESTful API.
The whole idea of RESTful service is that every resource is uniquely addressable using a universal syntax for use in hypermedia links and each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP".
I'm a bit confused on session... normally, when a user logs in the sessionID is recorded somewhere on server? Then when user makes another request, url sends this sessionID back to server and if the ID is valid proceed with request.
Do I have this right?
On the other hand with rest the request message basically sends the username/password everytime a request is sent.
Do I have this right? Using REST on my webapi, can I skip the whole concept of SESSION and just keep sending username/password... or is there a better way?
can I skip the whole concept of SESSION and just keep sending
username/password... or is there a better way?
Yes, Web API has Token based Authorization - Bearer token. By using it, you can totally avoid using Session State.
Secure a Web API with Individual Accounts and Local Login in ASP.NET Web API 2.2
In a nut shell, when a user is successfully authenticated, server issues a token instead of session state. Then every request, the user sends the same token along with the payload.
After going throught lot of comments from different people about session management for Rest supported applications, here what I have thought of doing.
My application can be accessed from Browser (as a normal web app) and Mobile devices as well. Application was written with 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, generate a http session 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.
Can somebody review my approach and confirm if it is fine?
Now, I have a second question - We are using JsonPRequestBuilder from GWT to invoke my back end REST services with jersey-guice. How do I send this token in http header during jsonp call from GWT?
"Session in REST" is an oxymoron.
When user logs in with mobile device, we are creating a unique auth token
Seems fine, though it looks a bit like you reinvented OAuth.
generate a http session and we store the http session with this token ID as key, value map in app.
Keeping some cache on the server-side for faster access is fine, but don't call it a session, and don't bind it to a specific token (you can bind it to a user if the data is user-specific; the user ID would simply be part of the cache key if it makes sense).
You don't talk about expiration of that cache, or how/when you clean it up and free memory.
Now, I have a second question - We are using JsonPRequestBuilder from GWT to invoke my back end REST services with jersey-guice. How do I send this token in http header during jsonp call from GWT?
As #Arcadien said, JSONP is just about inserting a <script> element in the page, so you only have control of the URL, and thus this is where you should/can pass the authentication token (albeit not being really secure).
May I question the reason you use JSONP from a mobile "native" app? AFAIK there's no SOP issue from UIWebViews or similar, so a RequestBuilder or XMLHttprequest would Just Work™.
For the second : with JSONP, you have to add your token as plain http parameter, you have no access to an object like Request when using regular XMLHttpRequest. So you can't set any kind of headers, everything should go in the query string.