I have created page type External URL and assign some permission but page can be open by any users either not log in or non authorized users.
I want to provide some roles to access that URL.
This is by design, DNN does not care about the permissions for external Urls.
The only way to go is adding a "normal" page and add something to that page that redirects to the external page, e.g. some JavaScript. You can use Will Strohl's Content Injection module for that.
Related
I'm using the Microsoft.Identity.Web NuGet package in order to sign users into Net Core 3.1 WebApp using Azure AD, then once the user has signed in, I then use their token with scopes to call the MS Graph API to fetch some additional data from their profile, such as their forename, surname, username etc. Basically some additional bits of info about the user that is not automatically included in the token returned from Azure AD.
This part work is working fine.
What I want to achieve is configuring some form of a system event or trigger to tell me when the user has successfully signed in, I would then use this trigger to run the Graph API query and fetch the user's additional profile attributes. The reason I want to do this is so each time the user requests a new page and runs a method or action, I can include their additional attributes into the logging.
Because the Microsoft.Identity.Web package hides away the Account Controller somewhere within the NuGet package (assuming a dll or something) I can't seem to access it to look at what I could latch onto in the way of an event trigger that I can use for the above.
Unless I call the MS Graph once the user has logged in then I would not have access to some of the user profile attributes that I want to include in the Serilog Logging structure.
Once I have the user attributes needed from MS Graph then I assume the best solution would be to store them in memory as getters setters for the lifetime of the logged in session, that way I can then access them from any page model / controller within the app through DI or a model.
I had thought about just simply calling the MS Graph from a OnGet() method when the home index page is loaded after a successful login, but the challenge is a user might not necessarily login by visiting the home page first, they might have saved a bookmark to another page they want to go to straight away which means the OnGet() method in the Home page might never be run. I need a more bullet proof solution given I should ensure that these extra user profile attributes are fetched every time without fail, regardless of which page is first visited that prompts the user login process.
Note: I've observed the fact that if I go straight to a page that has authorization enabled, once logged in then OIDC just returns me to that same page.
The final step in this riddle would be to remove the saved user profile attributes from memory once the user logs out, but this should be easy enough given the logout session always returns me to https://localhost:5001/MicrosoftIdentity/Account/SignedOut
If anyone has any ideas on what I could work with using this library to achieve the above would be great, thanks
I found something within Microsoft Identity Web, for the custom code:
AddSignIn has another override, which takes delegates instead of a
configuration section. The override with a configuration section
actually calls the override with delegates. In advanced scenarios you
might want to add configuration by code, or if you want to subscribe
to OpenIdConnect events. For instance if you want to provide a custom
processing when the token is validated.
https://github.com/AzureAD/microsoft-identity-web/wiki/web-apps#using-delegate-events
Here are Microsoft code samples for the ASP.net core, for many cases:
https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/
I want to use IdentityServer4 as a common login for my own web applications.
Not all users are free to use all apps and obviously I could make all apps have users be rejected that aren't allowed to access them.
It seems a little more elegant to have a common "this app isn't activated for you" page centralized in the identity server though. That way, I need to implement that page only once. The identity server would have to have knowledge about which user may access which client, but that's reasonable in my scenario: they are all my own apps anyway.
I'm not sure what the right place is to hook the test in. It can't be the login page as the user may already be logged in to the identity server from a client he does have access to.
I wouldn't go for this approach, but I do not know the design of your apps.
I think that the url may confuse the user. Since it is the url of the IdentityServer where they see the "this app isn't activated for you" message. What does that mean to the user and where to go from there?
Besides, IdentityServer is meant to authenticate users, not to authorize users. So it doesn't seem right to move this kind of logic to IdentityServer. It also sounds like extra work.
Keep it simple. Keep authorization close to the resource and create one page with the message. Copy that to all your apps and css does the rest.
And use the default behaviour. In case an anonymous user hits a secured method, the user will automatically be rerouted to the login page. In case an authenticated user hits a method where it doesn't have access, it reroutes to the default (apps) Account/Denied page.
You can override the path in you startup configuration:
.AddCookie("Cookies", options =>
{
options.AccessDeniedPath = "/accountdenied";
})
You can show the "this app isn't activated for you" page, or you can go from there and redirect with code to the IdentityServer page. With the possibility to add additional information to customize the page.
Perhaps you can enter the page of IdentityServer instead, if that fits your design better. I haven't tried it, so I do not know if that's possible.
But in any case I would keep the authorization logic in the app.
I have configured my first application in Windows Azure Active Directory and everything works fine: I can login using accounts in my directory.
However, I'm not entirely clear on all the concepts yet, especially the sign-on url. The tooltip says:
The URL where users can sign in and use your app. You can change this later.
But users sign in somewhere on login.windows.net and furthermore, it doesn't matter what I enter here, authentication keeps working. So what is this 'sign-on url'?
If you visit http://aka.ms/myapps, you'll find a long list of applications that have access to your account. If you click on these apps, you should be redirected to a home page where the sign-in process could be initialized. However, if the app doesn't declare a signInUrl in its manifest, you'll get an error that says the app is misconfigured.
something went wrong...
You cannot access this application because it has been misconfigured. Contact your IT department and include the following information:
Undefined Sign-On URL for application "BlahBlahBlah"
In the new Azure portal UI, the "SIGN-ON URL" is now called "Home page URL", which you can find under Branding in the app registration configuration.
I can see why this may be confusing. I think you can look at this as the URL where the whole sign-in process starts (i.e. your app's URL, which, if they're not logged in, will sends them to login.windows.net).
Also, even if for now you might be able to enter anything and authentication still works, I'd try to make it point to the right place just in case things change in the future.
It appears to me that It has significance with respect to wsFederation realm value when user sign out and redirected to Active directory sign in page.
When you add your application to azure ad, it gives you client id and key. When you use that in MVC webappp, you will see that there is an entry like below in web.config:
<system.identityModel.services>
<federationConfiguration>
<cookieHandler requireSsl="true" />
<wsFederation passiveRedirectEnabled="true" issuer="https://login.windows.net/{some guid}/wsfed" realm="https://localhost:44304/" requireHttps="true" />
</federationConfiguration>
</system.identityModel.services>
Copy the value of user to sign-on url.
In DotNetNuke, Administrator only can add new user. I want to allow other user with custom role as well to Add New User. Is it possible with DotNetNuke ?
It used to be possible, though I haven't tried this in quite a while.
Basically what you can try a couple of options.
1) You can assign PAGE permissions on the User Accounts page in DNN to users of a specific role. Then you will need to provide those users a LINK to the page, as they won't see the admin menu and won't have access to the link via the Admin menu.
2) You can actually (used to be able to) place the User account module on a page that other roles have access to, the problem is that the User Accounts and Security roles modules are "premium" meaning that you have to specifically (as a superuser) allow them for use in a portal before they can be placed on a page. You do this from the host/extensions page and click on the edit pencil next to the module, find the premium section then assign it to the specific portal. Then you will add the module(s) to a page, you'll find that more than just the User Account module gets added, so you will want to remove the extra ones by deleting them from the page.
Hopefully one of those two options will work for you.
I am working on a chrome bookmarking extension with google app engine as the backend. I am the only user now but I thought that if in the future there are other users the url needs to include the user name for the extension to interact with the backend. So I was thinking to change
http://ting-1.appspot.com/useradminpage
to
http://ting-1.appspot.com/user_name/useradminpage
where "user_name" is the gmail user id.
But I looked at twitter url and I see that they have
http://twitter.com/#!/user_name/
What is the purpose of "#!"? Is my scheme good enough in this case?
The # in a URL signifies the 'fragment identifier'. Historically this has been used to identify a part of a document identified by an 'anchor' tag, but recently webapp developers have begun to use it to pass information about the page state to Javascript code running in the page. This is used because it's possible for Javascript code to modify the fragment of the current page without causing the page to reload - meaning it can update as you browse through the webapp, and go right back to where you were when you reload the page.
The fragment is not sent to the server when the browser loads a page, so Twitter's server just sees a request for twitter.com; it's up to the Javascript code in the page to examine the fragment and determine what to do after that.
In your particular case, assuming you're using the App Engine User service to authenticate users, you have a number of options for how to distinguish users in your URLs:
Use their email address. In theory this can change, and users may not want their address in a URL they will share. If the URLs are private, this is more or less a moot point.
Use their user_id. This is opaque and reveals no useful information about the user, so it's safe, but it's also meaningless and hard to remember.
Let users pick a nickname for their URLs, like Facebook and other services do, on a first-in, first-served basis.