I'm at a client site where they have an application which began in SharePoint and is slowly migrating away to a very custom ASP.NET application. Some of their data elements are still hosted within SharePoint lists, two of which currently in question are some "Notes" and "Tasks" (fairly simple data elements in their SharePoint setup, nothing special about them). One of the things I need to be able to do from within ASP.NET is to automatically create some new items for these lists and add them from code.
So far it's pretty easy. I found the existing web part which handled the editing for those items, attached the debugger to it, tracked how it got its values and what it added to the list, etc. However, one of the fields being added to the list item isn't quite as obvious. In the existing web part UI, the field looks like this:
Essentially, it's a field for entering a user from the current Windows domain. The book icon opens a pop-up which allows the user to search for a name, etc. In my current testing, I'm running as local Administrator on a development machine. So I just look for "admin" in the pop-up and it populates the field with "[machine name]\Administrator" as expected. Then, in debugging, the value that gets pulled from the field and entered into the SharePoint list item is "1" as opposed to a name or anything like that.
I assume that "1" is an identifier for the local admin account. Makes sense, after all. But my question is, how can I get that identifier for the current logged-in user in code? I've found code to get the current user's name, but not any kind of numeric (even though it's a string) ID.
Additionally, this wouldn't just be happening inside of an ASP.NET application context. There's also a WPF client application for laptops which would be generating these list items and synchronizing them back to the server when connected. I'm currently operating on the assumption that the client user would be logged in with a proper domain account known to the server.
I imagine this is pretty easy, I just haven't stumbled across what I need quite yet.
I suppose you're looking for this:
int userId = SPContext.Current.Web.CurrentUser.ID;
By the way, this is the internal Id assigned by SharePoint to the user. To get this Id from a WPF application, you could deploy a WebService inside SharePoint that would return this Id. Or you can even query the SharePoint database, but I'm not sure if it's safe :-)
Related
We have SharePoint 2010 application with contains Custom Web Parts. A single web part usually contain around 200 UI fields. Some of them are enabled and few are disabled with default values that will be loaded based on the logged in user.
Recently we came across an issue, user while submitting the application can use FireBug/DOM Explorer or some other developer tool and can tweak the disabled fields which finally submits the wrong values to the database.
We are trying to use Session Variables to store these default values and while storing them to database taking these values from Session instead of taking them from UI form.
Please let me know whether there is any better way to prevent such hacks in SharePoint?
I have been tasked with making my company's Web App available offline. Before I move to the actual development phase, I want to be sure that my current strategy will not turn out to be a bust.
I first thought about using html5 app cache but after doing some tests I found that it seems to not cache the server side operations but the actual html that is rendered (Please correct me if I'm wrong). This will not work because the rendered html depends upon who is currently logged in. From my tests, it always rendered the html as if the last person that logged in (online) is logging in.
My current strategy is this:
I cache only the login page and an offline (.html) page to correspond to each aspx page that will need to be available offline. Every successful login (online) results in creating or updating Web SQL Database or IndexDB (depending on browser) with all data needed for that person to operate offline including a table that will be used for login credentials. In this way the only requirement for logging in offline is logging in with your login credentials at least one time.
My concern is that I am overcomplicating it. In order to make this work, I will need to create an html page for each current page (a lot of pages) and I will have to rewrite everything that is currently being done on the server in JavaScript including validation, database calls, populating controls such as dropdown lists and data grids, etc. Also everything that I change in the future will require a subsequent offline change.
Is there an established best practice for what I am trying to do that I am overlooking or am I venturing into new ground?
Please refer to these links, which gives you some insight on what is to be achieved. I'm not sure these are best practices, but these will be good starting point.
http://www.c-sharpcorner.com/UploadFile/aravindbenator/offline-mvc3-application/
http://www.developerfusion.com/article/84438/isolated-storage/
I'm doing some research on security and sitemaps in ASP.net and am unfortunately running short on time. I have not worked too much with ASP.net security so I'm not completely sure if I'm heading in the right direction.
Here is my problem:
I have a public website (i.e. on the internet) that will allow any user to sign up to. The website will be developed using ASP.net webforms. These users may create other users and assign these users different roles.
Different roles have different restrictions and the menu is displayed appropriately. For example, a user acting as an administrator can see all menu options. Whereas a limited user will only see some of these menu items.
There needs to be the ability for users on our end to modify what pages certain roles can access. For example, if Role1 can do task X, we would like to be able at some point modify Role1 to no longer do task X. This would be done using an application built in-house.
User types (roles) are to be saved in the database. User permissions (what pages each type can have access to) are also to be saved saved in the database.
Here is something I am thinking of doing:
Implement the authorization and authentication set up built in to ASP.net using the web.config file
Use Sitemaps to dynamically create menus/breadcrumbs from the database
I believe it is possible to do the second one using custom providers (please correct me if I'm wrong). But I am not entirely sure if it's possible to configure the web.config file dynamically.
I suppose this is really more of a yes/no answer but I would just like to make sure I'm not going in the wrong direction. I will be using VS2008 and .net 3.5 framework.
Many thanks.
Yes, it's possible to do what you're saying. You can dynamically create the sitemaps using a custom SiteMapProvider, see this articlet http://www.codeproject.com/KB/aspnet/dynamicsitemap.aspx.
You can also modify the web.config at runtime using an XmlReader or if you prefer, just reading it into a string and parsing out the authorization element. I'd put it in a separate file, though, using configSource:
<authorization configSource="auth.config" />
Then you only need to modify that file and not worry about messing up the web.config
I'm writing a pretty straight forward ASP.NET MVC web app: only a couple of CRUD pages, some folders where clients can browse documents and just 3 or 4 roles. The website will be used in a B2B scenario, where every client will have their "own" website.
At this point, the only thing that will change in the website, from client to client is the content (ie. the documents, and the rows of data they'll see). If this is the case, what's the best way to manage roles across all of my clients? I'm looking for the simplest possible solution because this is a proof of concept and I don't want to invest a lot of time right now.
What if it's not just the content that changes? Maybe some clients will want a few custom static pages. At this point, is my only option replicating the entire website? I'm leery of this because it'll become hard to maintain if I get a lot of clients.
I'd appreciate any help... I just don't want to shoot myself in the foot; I'm sure someone has done this before.
I create Virtual Directories in IIS for each client, all pointed back to the same folder where my ASP.NET code resides.
This allows me to support several dozen nearly-identical "web sites," each with their own database that is basically identical in form, only differs in data.
So, my site URLs look like:
http://mysite.com/clientacme/
http://mysite.com/clientbill/
http://mysite.com/clientcharlie/
There are two key implementation details I worked out for this:
I use the Virtual Directory folder name to determine which DSN my code reads from. This is accomplished by creating a simple static method that injects the folder name into a DSN string template. If you want to use the same database to store everyone's data, you can use the folder name as a default filter in your queries.
I store the settings for each web site (headers and footers, options, links to custom reports, etc.) in a simple "settings" table in each database (key, value) rather than in the web.config (which is shared). This allows me to extend the code base over time to customize the experience for each client without forking the code.
For user authentication, I use Basic authentication, and I keep usernames, passwords, and roles in a table in each database.
The important thing is that if you use different SQL Server databases for each client's content, you need to script any changes to your database tables, indexes, etc. and apply them across all databases at the same time (after testing of course). One simple way to do this is to maintain an Excel sheet with a table of database names and a big "SQL" cell at the top. Beside each database name, create a formula to "USE databasename;" and then concat the SQL code at the top.
I'm not sure if this answers your question completely, but as far as maintaining custom "static" pages I found myself implementing a system on a client's MVC website where the client can create "Pages" from their admin control panel and each Page has a collection of "PageContent" entities which consist of a Title and and HTML content field (populated using a WYISWYG editor). Upon creating a page the MVC application maps http://yoursite.com/Page/Page-Url-Specified-By-The-User to that page and renders its content there. Obviously, the pages are dynamic, but as far as the client can tell they have created a brand new custom page with little or no effort.
Two web applications I'm working with are using the ASP.NET membership and each have areas for user information which use this Property name/value storage method in the database.
Here is an example:
PropertyNameValues
publicEmail:S:0:19:yahooIM:S:19:0:timezone:S:19:2:commonName:S:21:4:birthdate:S:25:81:signatureFormatted:S:106:0:gender:S:106:1:fontsize:S:107:1:signature:S:108:0:dateFormat:S:108:15:enableEmoticons:S:123:4:webLog:S:127:0:enablePostPreviewPopup:S:127:5:location:S:132:12:bio:S:144:0:webAddress:S:144:0:interests:S:144:0:icqIM:S:144:0:aolIM:S:144:0:language:S:144:5:occupation:S:149:0:msnIM:S:149:0:
PropertyValues
someemailhere#here.com-6Asia<?xml version="1.0" encoding="utf-16"?>
<dateTime>0001-01-01T00:00:00</dateTime>20ddd, MMM d yyyyTrueFalseTest Testing-US
I can see the jist of how it works, name values show at what length in the property value string to begin grabbing and when to end - but is there an existing function to split these apart into an array or something?
Thanks!
How this works depends on if you are using a "web site" or a "web application" project type. If you are using a regular asp.net web site project, you will have a dynamically generated Profile object you can use to fetch user properties from.
If your application is MVC or a Web Application Project though, you will have to make your own profile object. I recommend you grab the web profile builder. This tool creates the ProfileCommon object that is needed to get at the profile data.
In general, I personally have found through repeated exposure that the Profile provider system supplied in asp.net is quite dreadful for storing actual user information (the kind of stuff you are using it for). The profile provider mechanism is great for stuff like user preferences (stuff usually called personalization) such as "always show details" or "I prefer the green background". The reason is that the profile system only makes the profile data easily accessable within the request of the one user. If you have admin tools that need to read from multiple user's profiles, you will find that performance will quickly degenerate, and getting at the profile data is actually quite difficult.
For these reasons, I recommend that you consider not using the profile system for the kind of data you are storing there. You will be a lot better off rolling your own tables and objects to store and fetch this particular kind of info. But if you never need to access the data for more than one user at a time, the built-in profile stuff is alright.
It looks like you're referring to the ASP.NET Profile system.
Within the code-behind of an aspx page, just use Profile.publicEmail, Profile.yahooIM, etc. There's an automatically generated class that parses that out for you. See the linked article for more details.