We have an angular application with node as the back end. We have an authenticate server where session management is done. There is a http interceptor that we are using in order to check whether a session is live in order to execute the http request. If the session has expired we navigate to Login page. And this works for most of the pages as we have some or the other http request in ngOnInit and hence they work fine. But I want to know how to intercept when there are no http requests on load. How do I encounter this? Should I use canActivate? Any suggestions would be helpful.
Thanks
Yes, you can use the canActivate hook of the Angular Router for doing this. You don't want to repeat the login check code in every component, canActivate can by reused in other parts of the application in the router config declaration. You can also check if the user has permissions to see this page.
What you can also do is to make the request and wait for the response, if the response is 403 the HTTP Interceptor routes back to the Login page.
If you don't want to check every time, you can use local storage to save the start session date and check if that is expired.
Related
I'm developping a webapp linked to a CAS server with phpCAS. Up to now everything was going well, I was able to access my app after the CAS authentication. I'm now supposed to implement a logout feature : when someone logs out of the CAS server, it sends logout request to all apps opened for that session.
The problem is my app doesn't seem to receive that request. I contacted the adminstrator who told me that he can see the request leaving the server. He then asked me to confirm him that my server received that request.
And here is the problem : I have no idea how to see if the server received the logout request (a json file...apparently a POST Method is used to send the data to the address of my app...as you see, I have no idea what I'm talking about.). I've been searching for days now and I'm totally in the dark. I tried to use tcpdump. I see a TCP F Flag when I logout of the CAS server so it seemed first like a good thing. But I have no idea how to see if my server has received a logout request.
Hoping that someone can help me...
Thanking you in advance.
And here is the problem : I have no idea how to see if the server received the logout request
You need to design some kind of filter/interceptor that sits in front of your application and intercepts all requests. This filter should examine the request body to see if the request is indeed a logout request. If it is, parse and consume the request body and begin to logout and remove the application session accordingly.
...with a little bit of searching and effort, it looks like phpCAS can handle logout requests on its own:
https://github.com/apereo/phpCAS/blob/master/docs/examples/example_logout.php
apparently a POST Method is used to send the data to the address of my app
Not "apparently"; rather, exactly. According to the docs:
The CAS Server MAY support Single Logout (SLO). SLO means that the user gets logged out not only from the CAS Server, but also from all visited CAS client applications. If SLO is supported by the CAS Server, the CAS Server MUST send a HTTP POST request containing a logout XML document (see Appendix C) to all service URLs provided to CAS during this CAS session whenever a Ticket Granting Ticket is explicitly expired by the user (e.g. during logout). CAS Clients that do not support the SLO POST requests MUST ignore these requests. SLO requests MAY also be initiated by the CAS Server upon TGT idle timeout.
And then here is the actual payload.
I wish to implement an Auth handler for requests that handles authentication with an OAuth Authorization server to allow the following:
import requests
requests.get(url, auth=KeycloakAuth())
What I've done so far is to apply a response hook when KeycloakAuth is called, so that when the client redirects the caller to Keycloak, the hook will see the Keycloak login page, post the credentials to Keycloak and get redirected back to the client.
However, this does not work for a POST, as requests makes a POST to Keycloak's login page instead of a GET due to the redirect. Keycloak doesn't return the login form in response to a POST and this fails.
I considered checking for the redirect in the response hook so that I can modify the redirect to do a GET to Keycloak instead, but it seems like requests' implementation of redirects bypasses all the hooks.
After poking into this a bit more, I believe this may be the wrong question to ask.
I was seeking a solution where, regardless of the original HTTP method used on the client (GET, POST, HEAD, etc), the library would automatically login to Keycloak, and then "replay" the original request to the client and make it effectively transparent to the user of the library.
However, this can't possibly work with OAuth 2.0 without further state management on either the part of the library or the client, due to the redirecting.
Suppose the original request was a POST, with some data. After finding that the user is not logged in, the User-Agent will be redirected to the Authorization Server for authentication.
This means that the original request's POST data will be lost, removing the opportunity for any replay, upon the User-Agent being redirected back to the client after authentication.
With some state management, the POST data could be stored for replay - it doesn't make sense to store the data on the server side since the data could be arbitrarily large, which leaves us with the user of the library to do the state management.
However, that amount of state management should probably not belong in a library, since the library will have to handle lots of cases to guarantee only-once delivery of the request, for example, which would be expected by the user of the requests library.
As such, this Auth handler is probably not something we can implement in a library.
I have an issue with Worklight 6.1. I will describe the scenario below:
User logs in the app and a new session is created for him. Then he stays inactive for some time until the session times out. When clicking on a button, an HTTP request is performed towards an HTTP adapter. However the Worklight server (Liberty) sees that there is no active session for this user and returns the appropriate response that the user is logged out and the user is redirected to the login page. This is correct up to here.
When the user logs in again and is redirected to the landing page, the previous request seems to have been cached and is performed resulting in an error as the necessary information is not yet available. How can I prevent this request from occruring when the user re logs in?
Thank you.
it's not possible to prevent the original request from re-sending after authentication.
The logic of the authentication and the logic of the application are separated and the result of a successful login will be the invocation of the original failed invocation.
What you can do is add to the adapter procedure implementation the logic that makes sure all the information is available, and if not - send an empty response to the client and in the client do whatever you want to do when the data is missing.
This should be done for all the procedures that rely on the session state.
I've written my own login app to protect my api following the oauth-login-app example.
I've implemented the web server flow and everything works great.
My question is: how should I handle an authentication failure at step 3? How do I tell he client app that the authentication failed? The user could either press the cancel button, or refuse permission or just enter the wrong details.
When you initiate OAuth 2.0 (dance) with
/authorize
the user-agent land on /login page (created/hosted by you),
post redirect.
enduser(user-agent) submits the username/password
to the page hosted by you. Here you collect the credentials and
submit to Apigee, and if authentication fails, send a HTTP 401
response. Now your application should be in position to re-render
the login page and with a flash "invalid credential".
Now coming to if user is authenticated but rejects the authorization request in
consent page, you should redirect to the "redirect_uri" provided
by client, with error code.
How do I tell he client app that the authentication failed?
The login app will redirect the control back to the application redirect URI - with added error code/description in the URL as hash parameters. In case of success the URL is appended with code or token.
You can do this redirect from your login app directly but I would suggest to make the redirect call first to an Apigee Proxy and let Apigee Proxy send the redirect back to app. Both in case of success and failure. In this way you will have the benefit of using Apigee analytics that helps your understand how many OAuths failed for what reason etc.
EDIT:
You can use the same GenerateAuthorizationCode proxy you have built for the success flow. When login fails or succeeds, in either case you need to pass that information to this proxy. Generally the login app and this proxy should share this information using a common session store. You can not pass this information just using a redirect parameter because that can be changed by the client user agent. When you redirect to the GenerateAuthorizationCode redirect proxy, do so by appending a random session ID in the URL. That id can be used by the GenerateAuthorizationCode proxy to look up the login status from the session store. Then you can either send back a redirect with error or a proper oauth code based on if the login was successful. An easy implementation of the session store can be done using a distributed caching resource in the apigee gateway. Login app can put/get the session using an internal API. While the proxy can use policies to retrieve the session information.
If I have a Selenium test which is currently logged in (with HTTP Authentication) to a particular website, how can I cause the remote browser to forget the current authentication so that I can log in as a different user (while remaining within the same test)?
Is this basic authentication? If it is, you can modify the basic auth header in your request to log in as a new user. You'll have to use Selenium server as a proxy in order to modify the request headers, however.
It depends how you are handling authentication.
If you are doing it via a cookie that gets checked server side you could do deleteCookie or if you want to delete all of them on the page you could do deleteAllVisibleCookies
If you are keeping it within a JavaScript you could just use getEval and delete whats in the variables.