In my development environment my custom domain wired up to a custom membership provider has an anonymous user myDomain\Anonymous however when I deployed to QC it does not contain the anonymous user (other users work fine).
For some background, I need the anonymous user to lock down pages with the deny read.
The domains configuration for both instances are the same, see below:
<domain name="sitecore" ensureAnonymousUser="false" />
<domain name="extranet" />
<domain name="default" isDefault="true" />
<domain name="myDomain" ensureAnonymousUser="false" />
Any ideas? I'm running Sitecore 7 Update 2
It might be that you haven't set the switchingprovider correctly. So if you on one environment have: storeFullNames=true and the other environment have storeFullNames=false. This means that in one instance you have created "myDomain\Anonymous" and in the other instance you are trying to look after "Anonymous".
The property indicates whether domains should be included in the name.
Anyway, why don't you just set ensureAnonymousUser="true", then it will create the user for you?
Related
We're trying to leverage Azures deployment slots for an Umbraco site we've built.
By default Umbraco uses a DSN defined in the connectionStrings sections of the web.config and we want it to use the connection string for the deployment slot it's sitting in.
What we've tried
Azure deployment slots put all defined app settings (and connection strings) into environment variables and to access them we can use Environment.GetEnvironmentVariable() which works but there doesn't seem to be a way to tell Umbraco to do this.
So in OnApplicationInitialized() (in /App_Code/Core/UmbracoAppStart.cs) we loaded the connectionstring section from the web.config, grabbed the connstr from env vars, added the DSN to the connectionstring section and saved.
The correct connection string is grabbed and stored but this seems to recycle the app (due to a web.config change) and thus we just get timeouts. (Or Umbraco XML cache errors, or it takes 20 mins to load the page).
I know you can store the appsettings and connectionstrings sections in separate files. But the file attribute (that doesn't cause a recycle if the referenced file is changed) doesn't work on the connectionStrings section - only the configSource attribute and that DOES recycle if changed.
(from: ASP.NET web.config: configSource vs. file attributes)
Help
Has anyone found a way around this?
We simply need to get Umbraco to use the deployment slot connection string - not the one in webconfig.
I'm even willing to copy and paste blindly at the moment without understanding how it works - and I hate doing that :). But that's what happens when people agree when the client wants to go live just before Christmas...
You don't need to do any code to use Azure connection string or the app settings. Just give them the same keys/names as you have on your web.config and they will be used instead.
So if you have this on your web config:
<add name="umbracoDbDSN" connectionString="Server={server};Initial Catalog={db};Persist Security Info=False;User ID={user};Password={password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=300;" providerName="System.Data.SqlClient" />
Your slot configuration should be this:
To replace an app setting just use the same key. So for this:
<add key="umbracoUseSSL" value="false" />
You'd use this:
If you want the setting to be slot specific you have to activate the Slot setting checkbox.
I'd like to have the application at example.com use In Proc. And all other applications (example.com/app1, example.com/other_app, etc) use SQL state. Is this possible? I have created distinct application pools for each application.
I added a <location> element to all of my web.configs:
<location path="." inheritInChildApplications="false" allowOverride="false">
<system.web>
<sessionState />
</system.web>
</location>
This seems to keep everything separate now. I can now use "In Proc" in my parent app and "SQL session" in child apps and not lose any session data. (A complex object was lost in the parent app because (I think) it was somehow inheriting the session state from children web.configs.)
Should just work with multiple applications. This setting is per application.
Haven't you tried this?
I have liberty profile authentication working with MS Active directory. But I am not able to setup a role mapping to a group.
I have created a security role in my web.xml:
<security-role>
<description>Users who are authorized to do update and insert operations</description>
<role-name>AuthorizedUser</role-name>
</security-role>
And for full WAS with wmm I have mapped the role to a group in ibm-application-bnd.xml which works:
<security-role name="AuthorizedUser" >
<group name="mygroup" access-id="group:defaultWIMFileBasedRealm/CN=mygroup,OU=myorg,DC=mydomain,DC=AD,DC=myco,DC=com"/>
</security-role>
But this is not working with liberty profile.
Do I need to alter the access-id?
The accessId must use exactly the same realm name as your user registry is configured to have. For example, if your registry is configured thusly:
<ldapRegistry realm="myLDAPRealm"/>
Then your accessId values must take on the same value
<security-role name="AuthorizedUser" >
<group name="mygroup" access-id="group:myLDAPRealm/..."/>
</security-role>
The default realm name for the LDAP registry is "LdapRegistry", and for reference, the default realm name for the basic registry is "BasicRegistry".
As AJ_R pointed out, you can remove the access-id field entirely and let the access-id be generated automatically. More often than not, specifying the access-id value manually is not necessary.
The issue was b/c 'o' != 'O' in "memberOf", I don't think this was case sensitive in TWAS.
Customizing the MS Active directory groupMemberIdMap fixed the group searches:
<activedFilters groupMemberIdMap="memberOf:member"/>
Did you use the same realmName (defaultWIMFileBasedRealm) when configuring the MS Active directory?
You can also try removing the access-id (just use the group name) and let the liberty server generate it using the relamName defined for the registry to see if that would help.
I've read about the New Membership and Session providers, and the information in this article is that just changing the connectionStrings the database would build itself magically in my SQL Azure Database.
So, I first changed my connection to:
<add name="Project" connectionString="Server=tcp:xxxxxxxx.database.windows.net,xxxx;Database=xxxxx;User ID=xxxxxxxxxxx;Password=xxxxxxxxxxx;Trusted_Connection=False;Encrypt=True;" providerName="System.Data.SqlClient" />
When I tried to debug my app with the emulator, I got the error:
EFProviders require MultipleActiveResultSets=True for System.Data.SqlClient connection strings.
I researched about this error and realized that it was something related to Entity Framework. I tried to make an Entity Framework connection string with no success. In addtion, I read somewhere that SQL Azure doesn't support MultipleActiveResultSets.
So, I have 2 questions:
Is it true that if I run the application and register any user via website interface the Membership and Session tables, views and procedures will magically build in my SQL Azure database?
What am I missing to make my app run?
Detail: I didn't add any new item in Models folder. It's only AccountModels class, as it generates from MVC3 template.
Fortunatelly now I have the 2 answers:
Yes, it's true and very easy!
The mistake I did first time it was try to put MultipleActiveResultsSet as a new attribute in the connectionString line. The code have to be like this:
<add name="Project" connectionString="Server=tcp:xxxxxxxx.database.windows.net,xxxx;Database=xxxxx;User ID=xxxxxxxxxxx;Password=xxxxxxxxxxx;Trusted_Connection=False;Encrypt=True;**MultipleActiveResultSets=True**" providerName="System.Data.SqlClient" />
Edited
Now I found out other way to do that with AppFabric Caching for Session State. Just follow this tutorial.
I'm developing an ASP.NET MVC intranet website which needs to have a few different user roles (admin, editor, writer, etc.) and the backend uses SQL Server. I read this post by scottgu about role-based security and used that as a starting point. The steps I followed were:
Configured a DB using the asp_regsql.exe application
Set the authentication mode to windows
<authentication mode = "Window" />
Added a connection string entry to the Web.config,
<connectionStrings>
<add name="SqlRoleManagerConnection"
connectionString="Data Source=localhost; Initial Catalog=aspservicedb; Integrated Security=SSPI;" />
</connectionStrings>
Added a roleManager entry to the Web.config section,
<roleManager enabled="true" defaultProvider="sqlRoleManager">
<providers>
<clear />
<add name="sqlRoleManager" type="System.Web.Security.SqlRoleProvider"
connectionStringName="SqlRoleManagerConnection"
applicationName="MyApplication" />
</providers>
</roleManager>
Added some role code into the Application_Start() method of the Global.asax.cs file,
if (!Roles.RoleExists("Editor"))
{
Roles.CreateRole("Editor");
}
if (!Roles.RoleExists("Writer"))
{
Roles.CreateRole("Writer");
}
if (!Roles.RoleExists("SiteAdmin"))
{
Roles.CreateRole("SiteAdmin");
Roles.AddUserToRole("MYCOMPUTER\\Matt", "SiteAdmin");
}
Modified my controllers to use the roles:
[Authorize(Roles = "SiteAdmin")]
public class SiteAdminController : Controller
{
.
.
.
}
And this all seems to work at this point but I'm wondering if there is a better approach to handing roles or if there are problems with this approach. It's easy to convince oneself that the approach is a good one because it worked but I'd like to take a different approach now rather than later if this isn't the best approach to solving the problem. Elsewhere I'd read someone say this was "hack" but never really qualified why he wouldn't solve the problem this way. Your thoughts? Do you have a better what to solve this?
In some of my production MVC apps, I simply use the built in sql role provider. It works out of the box, your MVC3 templates will be configured to use it already. Simply open up the admin site from within Visual Studio and manage the security and add your roles, users, users to roles, etc and thats it. Do not use your web.config to manage what roles have access to what URIs, this has been recommended over and over to stay away from in MVC as more than one uri could potentially get to a single route, so you use (as you did) the Authorize attribute in conjunction with the automatic role management, and thats all you need. It's pretty simple.
Well there are two alternatives worth mentioning:
Configure your role based security right in the web config. This centralizes your security configuration, though it must be updated to mirror your paths / routing, so there's a bit of manual maintenance involved
Configure your role based security in the database and create custom Action Filter to read, cache, and apply these roles based on the logged in user. This is dynamic but a little more involved because you'll probably have to create an admin screen to edit the configuration.
Let me know if you need examples of these and I can link you.