I have a Seam 2 application (specifically 2.3.1). Currently the implementation for login is to always redirect to /home.xhtml. Right now I'm working on a request to be able to redirect to the requested view if it requires logging in, instead of always redirecting to the homepage after login. I found and successfully implemented that part with the following addition to components.xml:
<event type="org.jboss.seam.security.notLoggedIn">
<action execute="#{redirect.captureCurrentView}"/>
</event>
<event type="org.jboss.seam.security.postAuthenticate">
<action execute="#{redirect.returnToCapturedView}"/>
</event>
My question is, how do I expand upon that functionality to provide a redirect if there is no captured view to return to? For example, if instead of being brought to the login page because a page requires authentication, I navigate to the login page via a link on the public home page?
Related
Hi upgrading to Android 11 and following this guidance
https://devblogs.microsoft.com/xamarin/android-11-package-visibility/
However I dont understand the following query.What is this https scheme actually means?
Is it to allow to make https calls?
Suggestions?
<queries>
<intent>
<action android:name="android.intent.action.VIEW" />
<data android:scheme="https" />
</intent>
</queries>
Also is there a link of all of the queries and what they do?
The custom URL Scheme in Android is an in-page jump protocol, which can also be called URLRouter. It opens an Activity through a route similar to opening a web page, rather than directly jumping through an explicit Intent.
The URL Scheme method is to configure the activity in the manifest that can accept the Scheme mode to start. When a call is needed, the URI of the Scheme protocol is added to the Intent in the form of Data, and the activity is called implicitly.
You could read it at Deep Links.
Working on a DNN (9.2) module and am getting the following error in the DNN log file when trying to call http://dnndev.me/desktopmodules/rentalz/server.ashx directly from URL address bar in browser:
DotNetNuke.Entities.Urls.UrlRewriterUtils - System.ArgumentNullException:
Value cannot be null.
Parameter name: url
at System.Web.HttpResponse.Redirect(String url,
Boolean endResponse, Boolean permanent)
at DotNetNuke.Entities.Urls.AdvancedUrlRewriter.ProcessRequest(
HttpContext context, Uri requestUri, Boolean useFriendlyUrls,
UrlAction result, FriendlyUrlSettings settings,
Boolean allowSettingsChange, Guid parentTraceId)
When I remove the following entry from the Web.config file, the ASHX page works, but the rest of the site bombs out!
<add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule,
DotNetNuke.HttpModules" preCondition="managedHandler" />
Does anyone know what's causing this?
This request shouldn't be handled by the URL rewriter, it ignores ashx requests by default. You can go to the SEO Settings page, and check the Expressions tab under URL Management to see if ashx is listed in the Do Not Rewrite URL Regular Expression. You can also go the the Test URL tab and put your URL in to see what sort of rewriting the system is trying to perform.
You shouldn't use a handler anymore. It's an old technique that can easily create security flaws on your website. You should instead us Web API. It's so much easier to do as well.
http://www.dnnsoftware.com/wiki/services-framework-webapi
I am relatively new to authorization/memberships in asp.net, so pls excuse if I ask anything silly. I have been looking at lot of examples to implement a custom membership provider in .net (in stackoverflow, codeproject, devX, and www.asp.net) and coded based on that but somehow couldn't get it working.
My requirement - our organization heavily uses HP's Quality center(QC), I am developing an asp.net application, its login page will use QC'a API for authenticating a user. I also have a SQL database in which I'll store the QC users who have registered to my application (just store QC user id's in DB, not password, like I said, password authentication is done using QC API). There will be a user-roles table in my DB to define the roles for registered users.
Why use 'membership' instead of some simple 'forms authentication' - because maybe in future I want to decouple QC authentication.
So, with this I started with first step - developing custom membership class(named AutoCenterMembershipProvider) and login page. I only need validateuser method. following is the approach I took to start with:
1. Ask user for QC user id/password, user clicks 'Authenticate' button
2. login page's code behind-'Authenticate' button's onClick method- checks if user is found in SQL database and if found, then uses QC API to authenticate user id-password
3. Second set of controls on Login page is enabled - ask user to select which QC Domain and Project user wants to login. Options for Domain and Project dropdown lists are also obtained using QC API after authenticating user. User selects those and clicks Login button
4. On Login button's click - call Membership.ValidateUser(objQCSession.UserName, objQCSession.Password). Since user is already validated using QC api, for simplicity I just return 'true' from my custom implementation of Membership.ValidateUser. Then I call - FormsAuthentication.RedirectFromLoginPage(obj_ACUser.QCSession.UserName, True) to direct user to apps default page provieded in web.config's - app_FAs.aspx.
The issue is - after user is redirected to app_FAs.aspx page, it directs user back to login page. I am trying to find out the mistake or missing piece.
Web.config looks like below:
<authentication mode="Forms">
<forms loginUrl="~\Pages\Login.aspx" defaultUrl="App_FAs.aspx"></forms>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
<membership defaultProvider="AutoCenterMembershipProvider">
<providers>
<clear/>
<add name="AutoCenterMembershipProvider"
type="CustomMembership.Models.AutoCenterMembershipProvider"
enablePasswordRetrieval="false" enablePasswordReset="false"
requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
maxInvalidPasswordAttempts="100" minRequiredPasswordLength="100"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="100" applicationName="/" />
</providers>
</membership>
and customMembership class is like:
Public Class AutoCenterMembershipProvider
Inherits System.Web.Security.MembershipProvider
Public Overrides Function ValidateUser(ByVal username As String, ByVal password As String) As Boolean
Return True
End Function
rest all members are 'Not implemented'
any help, pointers to missing piece, mistake is greatly appreciated, thanks in advance
Authenticate button click code
Private Sub btn_Authenticate_Click(ByVal sender as Object, ByVal e As System.Web.UI.ImageClickEventArgs) Handles btn_Authenticate.click
objQCSession = Session("QCUserSession")
If Membership.ValidateUser(objQCSession.UserName, objQCSession.Password) then
FormaAuthentication.RedirectFromLoginPage(objQCSession.UserName, True)
End if
End Sub
Currenlty, 2nd step - btn_Authenticate_Click method 1 - is just to assign FormAuthenticationTicket to cookie, and redirecting user to app_FAs.aspx page. It doesn't really need Custom Membership Provider's features.
If I understand your problem correctly, I would change the logic like this.
1) After validating user for QC, create FormAuthenticationTicket like this in the same method.
FormsAuthentication.SetAuthCookie("UserName", true|false);
2) btn_Authenticate_Click (does something and) redirects user to app_FAs.aspx
You do not even need Custom Membership Provider. If you want to use Custom Membership Provider, you can implement in 1st step (Not in 2nd step).
Update: I can't delete this question, because the answer has been upvoted, yet it is not at all the answer to what I'm asking. I'd like to delete this, as it has been a week with no answer, and it's just dragging down my accept %. Thanks.
I have a strongly typed master page that includes information that is based on the currently authenticated user's UserId:
(Guid)Membership.GetUser().ProviderUserKey
Every other normal action/view would require the user to be authenticated prior to it being viewed, which means the user's information is guaranteed to be available.
The problem is, I'm only getting null reference exceptions when I attempt to access the user's info. from the site's master page. I'm guessing this is because there isn't such thing as an [Authorize] attribute that applies to master pages.
Do I have this wrong? Is there another possible cause?
Simple example:
My site's various pages all use a view model object that inherits the master page view model:
<%# Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage<Models.MasterViewModel>" %>
the authenticated user object is a property of this base view model. All pages require authentication, so anyone who isn't is redirected to the login view, which has been working flawlessly. So a simple attempt to make use of a user's property in a view is thus:
<%= Model.UserName %>
which I'll put in one of the views, as well as in the site's master view.
When the user is already authenticated, all works as it should, with the UserName being printed twice on the page. When the auth ticket is expired, or a new user comes along however, the page will not redirect to the login, but instead generate an exception that complains of a null reference coming from the <%= Model.UserName %> in the master view.
When I remove the <%= Model.UserName %> from the master view, and leave it in the normal view, it redirects as it should, without throwing the error.
I hope this is somewhat more clear.
Edit:
Maybe someone could offer a better way to access the authenticated user's information in the master page?
Edit #2:
I would be very interested to see any example of an authenticated user's info being accessed in the master page...this is a real head-scratcher for me.
Update:
I haven't accepted the answer because I'm quite familiar with how I can test whether or not a user is authenticated. I am curious to know why no redirection to the login page is taking place.
It's not because of the master page.
Membership.GetUser() will return the current logged-on membership user. If no user is logged in it will return null and that's what is causing your problem.
you can use an if statement in your master page to check if the user is logged in or not before using any user's info.
if(Membership.GetUser() != null )
{
// Use User Info.
}
The only way i manage to reproduce this error is if i add the violating codeblock to a masterpage that is referenced from pages that does not require auth, then look at'em without signing in.
If your masterpage is not used on your logon-page, it could indicate something else is not entirely in place. How's your routing and authentication set up? If your View gets instantiated before the redirect, so will your masterpage, which could provoke this behaviour.
not sure if this still applies in mvc2, but have you tried defining the loginUrl attribute in your web.config?
<authentication mode="Forms">
<forms loginUrl="/user/login" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
The default document feature is turned off in IIS and here's the situation...
My start page for my project say is A.aspx. I run the project and sure enough, A.aspx appears in the url of the browser. Like it should though, A.aspx finds no user logged in and redirects to Login.aspx like it should.
A.aspx:
if (Session["UserStuff"] == null)
Response.Redirect("~/Account/Login.aspx");
The login.aspx shows up BUT when the user Logs in, the code:
FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, true);
always redirects to "Default.aspx" and not "A.aspx"
I've examined FormsAuthentication.GetRedirectUrl and sure enough it returns "Default.aspx"
I'm stumped????
In web.config you could set the default page using the defaultUrl attribute:
<authentication mode="Forms">
<forms
loginUrl="login.aspx"
defaultUrl="a.aspx"
protection="All"
timeout="30"
/>
</authentication>
http://www.codeproject.com/KB/aspnet/custom_authentication.aspx Follow this
If you're using FormsAuthentication, your settings should be defined in the web.config. It sounds like you have a default setting in the web.config for DefaultUrl. You shouldn't need the session redirect though. FormsAuthentication should perform this for you. It doesn't hurt to check the session and force a SignOut() if you don't find it, but FormsAuthentication should perform this redirect.
From my understanding, when the user is redirectoed to your login screen, the Forms Authentication mechanism will add the url of the page that the user was originally tring to access, to the login url that that they user tried to access. For example, if you had a login page: http;//bob/login.aspx, and a user tried to access http;//bob/showmethemoney.aspx, then they would get redirected to http;//bob/login.aspx?ReturnUrl=showmethemoney.aspx. So, if you use the ReturnUrl to redirect the user after the user logs in, the user will always be returned to the resource that they were originally trying to get to.