I'm wondering if there's another solution to my problem, that's considered more the Sharepoint way. FIrstly, my site is an Internet site, not Intranet. The problem is, all I'm trying to do is save values/variables from page to page in Sharepoint. I know the issue with Session Variables, but this seems to be the only way I can see to accomplish this. I know there are webparts that can store this value, but am I wrong in thinking this won't be persisted from page to page?
Basically, I'll be extending the Content Query Web Part to dynamically filter it's results based off of a variable/value. The user chooses their 'area' from a dropdown, and the CQWP in the site will change and query results based off of this value (It will be a provincial structure as it is a Canadian site, so if someone chooses the province 'Ontario', this value is saved in a global variable, and these extended CQWP that are throughout the site, will get this value, and query lists flagged as Ontario).
Is Session variables the only solution?
Thanks everyone!
Session variables are not the only solution. You can use Browser Cookies as well.
Not necessarily the 'SharePoint Way', but it is an option.
The SharePoint way would probably be to use something in the user profile, although of course that's not as appropriate for an anonymous site. Don't worry too much about going outside the SharePoint way of doing things - with an internet site it's pretty much unavoidable.
I'd recommend a cookie rather than a session variable if you only need to store the one value - simple to use from either client or server code, and none of the potential storage issues you get with the session.
You can always use database to persist this kind of data. Not mentinoning problems with sessions in SharePoint farm scenario.
You can read or write or remove persist key/values in web or webapplication level, take a look at SPWeb.Properties Property.
string strKey = "YourKey";
string strValue = "YourValue";
if (web.Properties.ContainsKey(strKey))
// if property exists then update it
web.Properties[strKey] = strValue;
else
// if property doesn't exist then add it
web.Properties.Add(strKey, strValue);
web.Properties.Update();
Related
I am building an ecommerce website which should be able to handle guest checkout. When a user visits the website, they are considered "Guests" unless they register / log-in to their account.
However, even as a guest, certain information needs to be stored about that visitor (partially incase they make an account in the furture, but also just for the website to function for them) like their prefered currency, email (if provided), cart and its contents, and an order_id (if they placed an order)
My question is which of the following choices would be better for handling this?
By the way: I am using NodeJS's express-session in this project.
Creating a "User" object for all new visitors and adding the user_id to the session. In this case that user object would need a feild called is_guest: true/false to tell the two apart, and it would also need a is_logged_in: true/false feild so the front-end can tell whether to load the log-in form or the profile page because a user object would always be present.
Only creating a "User" object after an account has been registered through the register form, and storing all data about the cart and email ect. for guests on the session object instead.
I can see problems with both. 1) could result in a really large database if all new visitors create a user object. 2) could result in information being scattered more and the session object becoming cluttered (especially if the cart becomes large). Having never done something like this before, I would appriciate any ideas about objections or solutions to the approaches and what you think would be the best.
Both solutions are fine, and I've seen both being used.
I would guess that storing things in the database is more common. Since you will probably be logging user interactions in your database anyways, it won't take up much more data. Secondly it's slightly simpler to use the same function to render pages for logged-in and logged-out users.
If you don't use a database, you may wish to use LocalStorage instead of a cookie since there are size limits to cookies (although few carts will get large enough to reach that limit).
I am writing an MVC 5 Intranet site with Windows Authentication.
The site is a questionnaire with the first two pages being information and instructions, on the third page I request the user to sign a disclaimer, from then on the user can't access any other part of the questionnaire, if the disclaimer isn't signed. What I want to do is to persist the action of signing the disclaimer to the database so when the user returns I can check if he/she has signed on a previous visit in which case I omit this page. I can't quite figure out where do I persist this information to database and where do I load it, and also how do I persist this information on the session.
Any advice would be appreciated. I have seen the suggestion on this page http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
(see number 7) but I need to save more than just one piece of information I need to save an userinfo object.
thanks in advance.
Personally I wouldnt do it on the database, probably better doing this on the client.
You should just be able to simply set a cookie with a flag, if true omit the page(s)/Redirect else do nothing.
I guess the next question is 'do you need to know if a specific user has read the disclaimer?', in which case then store in the database as well for future reference. Depends if this flag is useful going forward or just to control the mecahanism.
Hope that helps.
Are .NET GridView DataKeys secure?
For instance, I put some ID into the DataKeys of some GridView, but I don't want some nefarious soul to be able to dig those ID's up from the client.
I've looked at the html source of a gridview that has some ID's stored in the DataKeys collection, and I was unable to see the ID's in open text anywhere; however, I worry that they may be stored in the ViewState - which we know isn't secure. I am hoping that the DataKeys collection is actually stored in the Session somewhere, which would make it secure - for the most part.
Anyone know the answer to this question?
ASP.NET rarely stores anything in the session by itself. DataKeys, just like all the other bloat, goes in the ViewState. Apart from the fact that it bloats your requests up, it should be fairly secure as long as you use the encryption features properly.
(I'm finding the need to keep mere IDs secret quite odd though, what's this about exactly?)
I have some user-specific data that I need to store in SharePoint and make accessible to the user through custom webparts. Let's say a list of favorite URLs. What would be the most straightforward way to store this information?
Some builtin propertybag for SPUser or similar that I'm not aware of.
SPList, associated through User column.
Custom database table, associated through SPUser ID.
Otherwise?
Sounds like a RTFM to me, but I'm probably asking google the wrong questions.
[Update]
We eventually stored this information in a simple list, in a fixed location, with a Person field to filter on. Perhaps the simplest solution indeed, but technically I think the marked answer below is nicer.
If you want to make them reusable across the site collection for each user you can add Fields to the User Information List. You can add a feature receiver to your web parts solution that can create this column or check to see if this column exists in the User information list to be sure that the Column exists.
The User Information list is a Standard SharePoint list that SharePoint uses to store user information.
To access the User Information List you can go to the Root web of the Site Collection and use the SiteUserInfoList property
E.G.
SPList userInformationlist = SPContext.Current.Site.RootWeb.SiteUserInfoList;
//Or
SPWeb web = SPContext.Current.Site.RootWeb;
SPList userInformationlist = web.SiteUserInfoList;
To access a users List Item you can use the Users Id to get the ListItem back from the User Information List
E.G.
SPListItem currentUserItem = userInformationlist.GetItemById(web.CurrentUser.ID);
If you are using MOSS you can store this information in the User Profiles and make it available across Site Collections this does not need My Sites to be enabled. You would need to use the User Profile classes to access this.
I would go for the properties on the user profiles. You do not want to store the information on the root web as it is not information regarding the root web.
Your example with the favorite urls, each user has a "quick links" collection on their profile. An ideal place for storing urls for each user. :)
Build a webpart that reads/writes a custom database and you'll have the flexibility to use the webpart across SiteCollections, WebApps, or even seperate Farms.
This was implemented where I work and it has been a big success. We needed a way to provide our end users a large selection of important, commonly used links. End users have the ability to display the links that are useful for their particular job function and have a webpart that can be put anywhere to reference those links that are important to them. You also have the ability for an “admin” to go to the custom database and update any URL’s that might change without the end user ever being impacted or ending up with a broken link.
This is a very good question.
Although I have no perfect answer, here are some things you can consider:
Store data in a browser cookie if this is feasible.
Store in the Site collection's rootweb in the Properties, keyed by the user's login ID. You may want to elevate when reading / writing the properties just in case the user has access to a subweb, but not the rootweb.
Here's the scenario:
You have two seperate websites that exist in different environments (I.E. different databases, different web servers/domains)
You have full control over the code for both sites, but from the above point, they can not directly communicate with each other's database
You must transfer user from site A to site B securely
What is the best way to implement this? Simply sending the user identifier between the sites via query string wouldn't be secure, even if encrypted, since someone else could obtain the URL. It seems like the standard solution is to pass the user identifier along with another temporary key that web site A created, and web site B knows about. If this is the case, what's the proper way of securely setting up the system with the temporary key?
Thanks!
I am doing something like this. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
If yuo want temporary keys(I might do something like this too), how about setting up a web service on A that B can call to to get the user ID based on the temporary key. This way it's a totally separate call, and can be secured.
Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
Additionally, another idea that you may want to try is to create a secure token that does not expose the user's information and pass it on. However, this requires both systems to have similar data to verify the token. As the other answer suggested, hashes are very good uses to create non-descriptive bits about sensitive information.
Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair. Problem solved. You need to make the login-id's at both ends uniform or use single sign on cookies. More details in the paper by Vipin Samar: "Single Sign on Cookies for Web Applications".
They can't get the URL/Passwords unless they go into the application code at one of the servers.
You need to pass information between Site A and Site B, but you don't need to make the user the conduit for that information.
Site B could have a web-service that allows Site A to create a session for the user. In this design the interaction would go as follows:
User clicks button on Site A
Site A calls web-service on Site B which passes a temporary login URL back to Site A
Site A redirects user to the temporary URL on Site B