I am working with a site that needs to use two different asp.net profile providers. They are both added in the web.config and the properties of each of them are listed there as well. I run into a problem when I try to enable a property that has the same name in each provider. Comment one out, and the site will at least load. Leave both in, and I get an error like:
Item has already been added. Key in dictionary: 'myfieldname' Key being added: 'MyFieldName'
The properties are entirely different (different types even), but I am missing how I would allow both to be used.
There must be some way I am missing as this seems like it could be a common problem.
I've only ever implemented a single profile system with a Web Application project. With the Website template, the functionality is out of the box. Profiles allow you to store some extra information per user when using the ASP.NET membership system. Profiles are stored in the database automatically when we add this extra information to our web.config file.
It makes sense that there would be a clash if you are using profile properties with the same names - a possible solution would be to create your own table mapping - for example, give 'MyFieldName' an alias in the web.config but map it to the real property name in your code. Since much of the functionality is out-of-the-box with the website template, you may be limited in the amount of customization you can perform.
The following links may help:
http://code.msdn.microsoft.com/WebProfileBuilder
http://weblogs.asp.net/joewrobel/archive/2008/02/03/web-profile-builder-for-web-application-projects.aspx
http://weblogs.asp.net/jgalloway/archive/2008/01/19/writing-a-custom-asp-net-profile-class.aspx
Related
I need to design a content system similar to the news article 2sxc application. However, in my situation I have a primary subdomain and multiple secondary subdomains each of which is a portal in a single install of DNN. I need the primary to be able to selectively share articles with the secondary subdomains. I also need the secondary subdomains to be able to have their own articles. I have explored creating a ghost content type on the secondary sites, but this doesn't seem to share the content. I have used the visual query designer with an App Data Source to pull data from the zone and app of the primary. Using this, I can pull the needed article data, however, it also pulls lots of meta data like the name of each field on the content type etc. So I assumed I could filter this stream by content type, but when I do that it removes all items in the stream. Additionally, I have tried using razor code to get the correct data, but have been unsuccessful. So:
What is the best way to accomplish sharing the articles as described?
What am I missing on the visual query designer that is causing it to filter all results when filtering by type?
Thanks
If I understand you correctly, for 2, you are using the App Datasource. In the docs (linked), have a look at the first screenshot and the note above it. By renaming the streams coming out of the source, you automatically filter on the CT.
And for 1, I do agree that using Queries seems like a great choice.
There are a few more options to achieve this BTW
You can just show a module of Portal 1 on Portal 2 using Dnn features to share modules
Use the mechanics described by #Jeremy in his answer
2sxc 13.2 will offer a new shared-global-app system which is actually meant for other scenarios, but could also be used here.
You could also provide the data on your primary site as a RSS or WebService, and re-use that on the target site
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
I have a website written in ASP.NET using VB. Users log into this site. There are many different types of users based on the department. Depending on the type of user, we need to have certain things displayed for some user types and other things display for other user types. I would like to have a system of displaying things based on that user type but not have a bunch of IF statements if possible. Currently we have a folder for each user type that has pages that are using a master page for that type. Those pages in come cases use user controls but in other cases do not. When they do not use user controls, we are getting duplication of fields across many of the pages. This is making maintenance and enhancements time consuming. The bad part is, if I were to put for example 'Contact Information' in a user control, not all of the contact information would be displayed for each type of user. Some types of users have somethings and other types of users have other things.
Please keep in mind, one of the main problems we have is, this website is already very large so I cannot completely redesign it at this time.
Does anyone have any strategies or resources I can look at to develop a really great and organized way of doing this?
While you can put a web.config in each folder to control access to each folder, this does not solve your issue with the UserControl. You will have to use IF statements in that control. But that doesn't seem like a big deal. It's just one control.
Controling security with web.config
Has anyone ever tried to integrate AspDotNetStorefront and Sitecore? I've been trying for the past couple of days to come up with a way to get the two systems to play nicely together, but it doesn't seem feasible from what I can tell. A couple issues I've run across so far:
Authentication between the two (AspDotNetStorefront has its own implementation, Sitecore just uses/extends .NET Membership)
The main DLL for AspDotNetStorefront is what pops up in the stack trace when I get yellow-screened, but that DLL is obfuscated so I can't figure out what the problem is.
The biggest issue is that we need to keep our existing AspDotNetStorefront application as an e-commerce backend and use Sitecore to do everything else. AspDotNetStorefront has a CMS as part of it, but it's really not an acceptable solution for anything but really basic content pages.
Any thoughts on how I might go about this?
EDIT:
I've decided to break this whole thing down into the different problems that I am facing at the moment and solve each one as efficiently as I know how. I'll detail the ones I have here and then update when I run into new ones.
Problem 1: Authentication between the two systems.
This one isn't too bad actually if you're knowledgeable about forms authentication tickets, which I wasn't at the time but am learning quickly enough. As long as the two systems share the same encryption info, it's easy enough to pass information back and forth between them using cookies as stated below in the accepted answer. The other kicker is that I needed to set the CustomerGUID in the AspDotNetStorefront Customer table to be the user ID from the Sitecore user tables (standard ASP.NET membership). So far this approach seems to work pretty well (I'm still in the proof of concept stage at the moment.
Another thing to keep in mind if you ever need to attempt this is that AspDotNetStorefront comes with a web service that you can use to basically do anything you need. Since they use the same encryption keys, I am able to log in on the storefront side using this service more securely than just passing over clear text passwords (I had to write the method myself, I don't believe it comes standard, if I am mistaken please let me know). Although I doubt it's a huge deal since it all happens server side anyways.
Problem 2: Getting at the product data
This one was a little more troublesome. The aforementioned web service has a few issues I've had difficulty working around. However, since the databases are going to be on the same server, I simply decided that since all I really need is the price and ID I would go ahead and set the ProductGUID column of each product in the Storefront database to match the Sitecore item ID of the corresponding item in the Sitecore database. This way I just need a quick query to grab the ProductID and price information which is only used in a few places. Everything else is going to be housed in Sitecore.
If anyone has anything to add feel free, as far as I can tell from Google, no one has actually done this before, so I'm having a lot of trouble finding resources on this particular topic.
UPDATE:
The integration is in fact possible and our site has been up for a week and a half now with very few integration related problems. This isn't something I recommend doing really on a personal level, but it is in fact possible to pull off.
I know ASPDotNetStorefront and other CMS systems (but not Sitecore). If I was approaching this, I would probably start simple and create a custom URL structure for sitecore 'content' pages that ASPDNSF would direct to Sitecore to handle. [possibly replacing the existing topics system in ASPDNSF]. So, for example: a URL such as www.domain.com/p-1234-aproductpage.aspx would be handled by ASPDNSF whereas www.domain.com/content/123/a-content-page would get sent to Sitecore to render. This is a straightforward web.config edit.
Security sharing across the systems should be possible across the same domain as the cookie information will be available (you should be able to create some code in Sitecore using the ASPDNSFCommon.dll and a cast of HttpContext.Current.User into a AspDotNetStorefrontPrincipal class to detect if a customer is logged in)
Another way to approach the problem would be to write a function that retrieved Sitecore content from the database based on a URL id and then write an ASPDNSF XML template to use the function to retrieve this content based on the URL. For example, you could create a custom URL structure in ASPDNSF such as www.domain.com/sc-1234-sitecore-content-item.aspx which is sent to your custom code; 1234 is used as the sitecore content id and the XML template retrieves the content and renders it on screen.
This second approach has the advantage of using Sitecore for all non-product content management while keeping the live application in ASPDNSF. Also one set of design templates and all your security issues go.
In ASP.NET what's the best way to do the following:
Show certain controls based on your rights?
For a gridview control, how do you show certain columns based on your role?
I'm thinking for number 2, have the data come from a role specific view on the database.
Instead of actually using roles to hide/show certain controls, I would suggest having another layer of permissions for each role and show/hide based on those instead.
That way you can redefine what permissions a role has and won't have to change your code.
Also, this allows you to make new roles in the future and just assign a set of permissions to the role.
As for controls, yes... I would just set the Visible property on the control based on the user.IsInRole("permissionname") value.
For grids I would do the same... set the Visibility of the columns to the IsInRole boolean value.
//Delete Icon Column
gridViewContacts.Columns[0].Visible = user.IsInRole("DeleteAnyContact");
I would make create your permissions in a very granular nature.. such as
ViewAnyContact
ViewOwnContact
EditOwnContact
EditAnyContact
AddAnyContact
DeleteOwnContact
DeleteAnyContact
Etc...
If you're going the role-based route, ASP.NET (since version 2.0) has had a variety of membership controls available which might help in this scenario. Assuming (and this could well be a faulty assumption) that you're using the in-box membership provider, you can actually use the LoginView control to get #1 handled.
The way it works is that the LoginView can use RoleGroups and their associated ContentTemplates to customize the view for the user based on role. This works seamlessly with the in-box membership provider; I believe if you build your own membership provider based on Microsoft's technology it will also work. (I haven't done this latter step.)
Conceivably, you could use it for #2, but it'd wind up with duplicated code and effort, which isn't my personal preference. I think your choice of using role-specific SQL views to drive that table may be better than this option. (There are other options as well, of course, which may be better.)
I will second Elijah Manor's recommendation of using permissions instead of roles. Generally, that's my preference as well. (And I was surprised to discover that the membership provider technology didn't go to that level.) In any permission-centric scenario, though, you will essentially have to roll everything yourself. (I've done this, and while it's very flexible, the code to secure any given page can get hairy.)
EDIT: I apologize; I meant to include a link for the LoginView control. DotNetJunkies has a tutorial on it.