On my current project, I use wicket and Shiro for authentication and authorisation. The problem is that for pages with an error code 404 the session is lost. Only mounted pages i.e. pages with a fixed path (/home, /users...) get a session, so when I type server:port/giberish the session is lost and I see the login page in the header. It seems that this behaviour is implicit because I could not find anywhere configuration for this.
Related
I'm a DevOps engineer who has inherited an AEM 6.5 environment from an AEM developer who is no longer with the organization. The architecture consists of one dispatcher instance, one author instance, and one publisher instance. Currently the dispatcher is configured to fetch and cache content from the publisher instance and serve content to users from the cache.
It works for all pages except login pages when the user attempts to visit a restricted page (any page which require the user to log in). When visiting a restricted page via the dispatcher instance (https://example.com/site/restricted.html) it performs a 302 redirect to the login page on the publisher instance (https://publish.example.com/site/login.html). This is the same behavior which occurs if a user visits the restricted page directly on the publisher instance (https://publish.example.com/site/restricted.html), but it is not the desired behavior for when accessing the site via the dispatcher instance.
I am trying to make it so that when visiting restricted pages through the dispatcher instance that the user is brought to the login page through the dispatcher (https://example.com/site/login.html), not redirected to the publisher instance. The user should not see publish appear in the URL at any time, nor should the existence of the publisher instance ever be made visible to a site visitor.
I've been unable to find where this redirect is defined/configured. Here is a summary of my research so far:
I have reviewed all Apache configuration on the dispatcher instance in httpd.conf and all conf.d files and there are no rewrite rules or redirects which seem to cause this behavior. There are no references to the publisher instance IP address, hostname, URL, or subdomain in any of the conf files or VirtualHost blocks.
I have reviewed all dispatcher configuration in the mod_dispatcher.so module's dispatcher.conf config file on the dispatcher instance and there doesn't seem to be anything related there either. The only reference to the publisher instance is in the /farms/renders block in dispatcher.any.
I’ve examined every configuration option listed in both the author and publisher instance configuration web consoles (https://publish.example.com/system/console/configMgr) which include any of these terms: login, redirect, restricted, authorization, and authentication but could not find anything that seemed relevant.
I’ve also searched in CRXDE Lite on both author and publish (https://publish.example.com/crx/de/index.jsp) for the same terms but didn't find anything relevant. I found the login.html page and it's child node jcr:content component but there's nothing about redirects in the properties.
I've gone onto the publisher server instance and checked the contents of /opt/aem/crx-quickstart/conf. I see bundles.json, cq.pid, quickstart.properties, and sling.properties but none of them have any clues.
I've found a file at /opt/aem/crx-quickstart/launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config which contains this:
:org.apache.felix.configadmin.revision:=L"1"
auth.loginselector.defaultloginpage="/libs/granite/core/content/login"
auth.loginselector.mappings=[ \
"/libs/granite/core/content/login:/login", \
]
but I'm not sure what that is referencing. There is no /libs/granite/core/content directory on the server.
Where else might this redirect behavior be defined?
Also check, in /system/console/configMgr for Apache Sling Resource Resolver Factory and the Day CQ Link Externalizer for possible mappings defined there as well.
Keycloak inserts session_state, state and code in url fragment params.. sometimes after successful login these remain on the url...
Or, when alternate routes are clicked in the app, these appear again.
Unnecessarily exposing the internals of keycloak params to users.
Is there some solution to not have these appear or delete them?
e.g. http://localhost:3000/home/#state=e625140e-c4f9-4500-858e-32c80e89f8a9&session_state=445229c3-d7eb-46e9-bfba-3339253dd17e&code=af0abde4-a60d-4f34-a101-8db5c76546b9.445229c3-d7eb-46e9-bfba-3339253dd17e.59915134-a59b-4ffb-878a-d02e7e84f2dd
Update:
with more tests narrowed down the issue to occur when
anything on the keycloak instance is touched. e.g. keycloak.token
any function call of keycloak is invoked... then after that these params get added and removed for every url route thereafter...
e.g. await keycloak.updateToken()
Keycloak Sever and js lib Version : 9.0.2
It is not a Keycloak issue. That's how used login flow works (maybe you need different flow, which will be more suitable for your use case). Your app code (used OIDC/OAuth library) should "clean" URL fragments. Cleaning can be: exchange code for the token (in this particular case), remove URL fragments, clean browser history, etc.
I am using ZendFramework2 with zfc-user and ZfcRbac for authorization and access control. I have setup everything to work with database managed role. Now when a user navigate to an un-authorized page, I am getting the error page You are not authorized to access this resource which is thrown by ZfcRbac
Actually I have configured in my zfc-rbac.global.php to redirect to the 403 page. my settings are below.
ZfcRbac\Exception\UnauthorizedException
--
'unauthorized_strategy' => [
'template' => 'error/403'
],
How do I send the user to 403 page?
EDIT
The right answer is to attach the UnauthorizedStrategy in the onBootstrap
$t = $e->getTarget();
$t->getEventManager()->attach(
$t->getServiceManager()->get('\ZfcRbac\View\Strategy\UnauthorizedStrategy')
);
ZfcRbac per default doesn't do anything but throw the exception. The power of ZfcRbac then lies within it's many, many customizable features. The one you should be looking at is found under the Documentation-Section "Strategies".
In short
register the redirection strategy on your Modules onBootstrap
if required, change the redirection strategies configuration
I have the following Auth object in my app:
App.Auth = Ember.Auth.create
signInEndPoint: '/users/sign_in'
signOutEndPoint: '/users/sign_out'
tokenKey: 'auth_token'
tokenIdKey: 'user_id'
userModel: 'App.User'
modules: ['emberModel', 'rememberable', 'actionRedirectable']
actionRedirectable:
signInRoute: 'home'
signOutRoute: 'login'
rememberable:
tokenKey: 'remember_token'
period: 7
autoRecall: true
Everything with authentication is working great. The problem I'm seeing now, though, is that when a user attempts to access, say, 'mydomain.com/#/articles/12' and has a valid remember token, accessing the application is tantamoun to starting a new boot of the application. The user is signed in via remember token, and actionRedirectable takes over and takes the user to HomeRoute instead of going to the requested resource.
I feel like I could get around this by manually transitioning the routes in the relvant login/logout controllers, but I wonder if there's a baked in way of solving this in EmberAuth?
ember-auth dev here.
This looks like a known issue. Try the fix in this comment from github issue #69.
In short, module order does matter. actionRedirectable needs to register the route (probably the article route in your case), before rememberable signs in the user and requests a redirect. Otherwise it would have nowhere to redirect to, and falls back to your home route as specified.
There have already been requests of fixing this unexpected behavior, but I haven't been able to find a fix yet - sorry.
I would to change the default login page (to /content/ethz_ch/Login)
I configured tha page by the Day CQ Login Selector Authentication Handler
In ./launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config I see
auth.loginselector.defaultloginpage="/content/ethz_ch/Login"
as expected.
I then configured a test page (/content/ethz_ch/de/auth_test.html) with a closed user group and left the login page field blank.
When accessing the test page, instead on the newly defined login page I am redirected to
https://..../system/sling/cqform/defaultlogin.html?resource=%2Fcontent%2Fethz_ch%2Fde%2Fauth_test.html&$$login$$=%24%24login%24%24
Any idea on what I am doing wrong?
In the Day CQ Login Selector Authentication Handler there is a Path Info setting which restricts the possible login pages:
A list of request extensions indicating requests for which the Login Selector Authentication Handler may request credentials. Any request whose extension is not one the listed extensions will not cause the credentials to be requested. If this list is empty the default list of html and htm is used. Note that the list entries must not have leading dots. Requests without extension or requests with trailing slashes (/) are always handled by the Login Selector Authentication Handler regardless of this configuration.
Specifying the Default Login Page with the full URL (with extension) solved the problem:
/content/ethz_ch/login.html