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
Related
So I am trying to use single sign on in an outlook addin. I have registered my app at https://apps.dev.microsoft.com/.
In my Manifest I have
<WebApplicationInfo>
<Id>{myId}</Id>
<Resource>api://mydomain.com:3000/{myId}</Resource>
<Scopes>
<Scope>Mail.Read</Scope>
<Scope>profile</Scope>
</Scopes>
</WebApplicationInfo>
mydomain.com is actually a domain i map to my local IP.
Outlook accepts my manifest just fine. How ever when i call Office.context.auth.getAccessTokenAsync, I get the following response
{name: "Invalid application resource Url provided.", message: "Invalid resource Url specified in the manifest.", code: 13004}
How else should i write the resource url. Am i supposed to add this url somewhere else?
I followed https://learn.microsoft.com/en-us/office/dev/add-ins/develop/register-sso-add-in-aad-v2 and was able to get further. But now i Get {name: "Preauthorization missing.", message: "Missing grant for this add-in.", code: 13005}
I was able to solve Error 13005 by adding /taskpane.html to the end of my redirect URI in the authentication tab of my App Registration [Figure 1]. Originally I just had https://loacalhost:3000 as my redirect URI. Just make sure that whatever endpoint the user is being redirected to is the redirect URI. Seems simple but I spent a lot of time on this.
If you can't figure out what your redirect endpoint is, inspect the taskpane element and then look at the top of the tab. It should be something like DevTools - {localhost:3000/taskpane.html}?_... The text inside of the curly braces is the endpoint, make sure that the whole string is added to the Authentication tab in App registrations.
App Registration Page Example Picture
I hope this helps,
Lucius
I am building an app with the use of ember-simple-auth.
So it looks very much like the library its doing is thing.
Here is what happens:
user tries to access /dashboard but is redirected to /
the route / contains the login form
the user logs in with valid credentials
Server responds: /token 200 0.252 ms - 52
But an error message is shown: Error: Assertion Failed: The route index was not found
user navigates to /dashboard and can now see the content, navigate around protected areas, and successfully log out.
My question is, how do I define /dashboard as the route instead of index? So that after successful login you are redirected to /dashboard
You can configure Ember Simple Auth's routeAfterAuthentication in the config, e.g.
ENV['ember-simple-auth'] = {
routeAfterAuthentication: 'dashboard'
}
4 years later...
On Ember Simple Auth Part, you can add routeAfterAuthentication and call it a day, because of ESA default to index.
If we dig deeper, as far as why ESA was and still defaults to the Index route, is that Ember always generates 2 routes for you:
one "" for ApplicationRoute
and "/" for IndexRoute,
You get these 2 routes for free.
I found 3.20 version doc's wording is verbose, so I'm pasting from 1.10 doc, but the idea remains the same
On that perspective, ESA uses IndexRoute as default is a safe bet.
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.
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 have a link pointing to restricted page. When I access the link directly in logout status, its redirect to 404. Actually it should redirect to login form.
I tried:
config {
typolinkLinkAccessRestrictedPages=PAGE_ID
typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###
}
Not working.
Also I tried the login status redirect plugin, no use.
Anyone know how to do this? I am using TYPO3 version 4.4.8.
As this is still unanswered, does this help?
Valid for TYPO3 < 8.x
# Check if user is logged in:
[usergroup = *]
# do something
[else]
page.config >
page.config.additionalHeaders = Location: http://www.yourdomain.org/login.html
[end]
I recently posted this to another questions and it crossed my mind that it might be a suitable workaround for your probem.
Found here
I'm not sure how to make redirection work correctly, but perhaps a bit of background will be helpful.
typolinkLinkAccessRestrictedPages only interacts with link generation. That way, anywhere you have a link to an access restricted page, you should get a link that points to the "PAGE Id" page. I suspect you are using your login pid in place of PAGE Id, which I guess should work, but I haven't used this particular feature. I have typolinkLinkAccessRestrictedPages = NONE which makes all links show up, linked to the correct url, but only users who are logged in will successfully load those pages.
If anyone, without being logged in, uses a bookmark to an access restricted page, or they click on one of these links, or directly type in the address, or whatever, they will run into TYPO3's 404 handling (with the error message: ID was not an accessible page). To change how TYPO3 handles these errors, you need to change what TYPO3 does via this setting in localconf.php:
$TYPO3_CONF_VARS["FE"]["pageNotFound_handling"]
I don't know if there's a clean way to just automatically redirect to the login page without hacking the pageNotFound_handling.
As far as the typoscript solution, that wouldn't work for my site, because the trigger isn't whether or not someone is logged in (often they will not be logged in)--the trigger for my site is trying to access a protected page when you are not logged in. I don't want it to redirect everyone who isn't logged in because a lot of pages don't require any login.
Fe_login cannot alone do this...
Follow these steps::
Install "pagenotfoundhandling" extention after felogin login
configuration.
Configure 403 page as login page in "pagenotfoundhandling" extention configuration.
Then, when you try to access "Access restricted page", "pagenotfoundhandling" will redirect to login page then pagenotfoundhandling handle redirect to again requested page. I have tested this on TYPO3 6.2.14
And I found an other workaround that looks like it should work fine.
# pages and subpages starting at 123 and 321 are restricted
[PIDinRootline = 123,321] && [loginUser = ]
page.headerData.666 = TEXT
page.headerData.666 {
data = getIndpEnv:TYPO3_REQUEST_URL
wrap = <meta http-equiv="refresh" content="0; URL=/passwort/?referer= | " />
}
[global]
Important notice: Do not restrict the complete page, only all contents of the page. Otherwise RealURL will trigger the 404 handler.
At the moment page.config.additionalHeaders (like used by #Mateng) does not support stdWrap, though you cannot add a referrer to redirect to the desired page after login (see TYPO3 Forge and vote for feature request).
Complete solution :
1. first in typo3conf/LocalConfiguration.php you have to add:
'FE' => [
'pageNotFound_handling' => 'REDIRECT:/login/',
"pageNotFound_handling_statheader" => 'HTTP/1.1 404 Not Found',
...
],
then add to typoscript :
'
config {
typolinkLinkAccessRestrictedPages = YOUR_LOGIN_PAGE_ID
typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###
}
plugin.tx_felogin_pi1.redirectMode = referer
'
Because there seems no proper solution for this behaviour of TYPO3, I use the following workaround with RealURL.
Create a 404 page in TYPO3
set the Speaking URL path segment to "404-error" and check
Override the whole page path
Add a text that describes what is happening (i. e. "Page doesn't exist or is restricted, please login")
Add the felogin plugin to that page and hide it when users are logged in
Set [FE][pageNotFound_handling] = /404-error/ in the install tool
This 404-error page is shown every time a user requests a page that he is either not allowed to see or a page that does not exist. When the user uses the login form on the page, he will find the proper content immediately after login because the URI did not change at all (when there is no redirect configured for the fe_login plugin).