I'm using /enrollments/orgUnits/{orgUnitid}/users/?roleid=XXX
Works correctly with numeric roleId (both existing and not existing).
When roleId is not numeric (eg "Instructor") the call doesn't throw an error and returns all enrollments in the OU.
That clearly sounds like a defect; I would encourage you to contact D2L's support desk and report it as such (so that you can provide details of your back-end service, like version and service-pack level).
Related
Using MVC when registering a new user a record gets created in webpages_Membership and UserProfile
The UserId by default gets created as sequential number 1, 2, 3...
my model
public class UserProfile
{
[Key]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
}
When I go to edit the record in the URL it shows /profile/1
I want to change the id's value to something random e.g. profile/f8934hre987f8987f9f8 for security reasons.
Same thing I want to generate random number when details gets viewed by members so instead
/details/1 want it to be /details/783787483743874873
The ViewModel for displaying the details contains Id field as a primary key which is also gets generated sequentially.
I read using [GUID] is not great for performance.
Advice how to change it without affecting the performance? Suggestions. Thank you.
EDIT
Have similar like groupon site, when user attempts to edit his/her profile instead of showing /edit/1 have something like:
So user doesnt know how many records in the database or what record number the user is.
I am not 100% sure what you mean by something random. I am assuming that you mean encryption. Please take a look at this MSDN link for the details on encryption.
After that ,you can have your action method like /detail/{encrypteduserId}
Then you can have action method like below
public class Detail(string id)
{
var decryptedUserId = GetDecryptedId(id);
// GetDecryptedId gives the decrypted information.
// You can implement it based on the MSDN link
// You can use decryptedUserId to run queries on the database.
}
This way you can achieve your goals without making schema changes. This seems like a minimum possible friction approach.
There is no security benefit to having a random user id, so long as your site implements proper controlled access. That is, nobody should be able to access /profile/1 except the user with a user id of 1 (or another user who is authorized to do so, such as an administrator). All other users should get an error.
An even better approach is to not use an id at all. Simply get the current users ID and show the profile of the currently logged in user. Then user with userid 1 just goes to /profile and they see their profile, and user with an id of 2 goes to /profile and they see their profile and there is no way for one user to see the others.
That's not always possible however, for instance in maintenance screens where an admin is viewing other users profiles, but in that case only the authorized admin should be able to do that.
Obscuring the userid is a false sense of security, since the id will be visible anyways. You are simply fooling yourself if you think this adds any security value, unless you haven't implement proper security in the first place, in which case it's just hiding your real problem.
It also adds needless complexity, and confusion. It's equivalent to saying "I want to change the address of my house to a random number for security reasons". Think of all the problems that would cause, for dubious results.
Having the User ID displayed in the URL is a genuine security concern, be it a simple integer user id or some GUID (if that GUID can be used to identify a user). This is especially true in cases of Transport layer security (HTTPS) where the URL is not encrypted like the content is.
Here are a couple of ways I can think of going around this:-
1.) As suggested by Erik above, use User.Identity.Name to identify the currently logged in user. This wouldn't however work for the administrator accessing another member's profile. It would also not work for unauthenticated scenarios.
2.) Instead of creating a direct hyperlink, create a form which posts the user id as part of a custom type (model). Then use model binding to access the User ID as a property of the custom model object in the Action method. In this case, the user ID is submitted as part of the form and hence is transported over the wire encrypted (if HTTPS) and not visible in the URL. This would work in both cases where a member is trying to access his/her own profile, or when an administrator chooses a profile to access on screen.
An example of scenario 2::
public ActionResult EditProfile(UserProfile userProfile)
{
bool success = false;
if (User.Identity.IsAuthenticated)
{
if (ModelState.IsValid)
{
if (WebSecurity.UserExists(userProfile.UserName))
{
// your code to update profile here.
}
}
}
if (success)
{
ViewBag.Message = "Profile updated successfully.";
}
else
{
ViewBag.Message = "Profile not updated:";
}
return View();
}
Wondering if anyone knows of any way to extend or configure Breeze so that the server returns additional info in the entity metadata? I'd like to use this additional data to assist with validation.
Assume I have an entity model like so with some Data Annotations applied:
public class Person {
[RegularExpression(#"^$|^http\://[a-zA-Z0-9\-\.]+\.[a-zA-Z]{2,3}(/\S*)?",
ErrorMessage="The Website address does not appear to be valid.")]
public string Website { get; set; }
[Required(ErrorMessage="The Name field is required."),
MaxLength(150, ErrorMessage = "The Name field cannot exceed 150 characters."),
MinLength(5, ErrorMessage = "The Name field must be at least 5 characters.")]
public string Name { get; set; }
//...
}
Right now, Breeze only hooks up a MaxLength and Required Validator based on the metadata it receives since this is all it supports out of the box. If Breeze could include in the metadata the info described in the Data Annotation Attributes on the server entity, I'm thinking it would then be possible for Breeze to automatically add additional stock validators to the client EntityType (e.g. for RegEx, Range, MinLength, etc... ). This would cover the majority of basic validation use cases. Or, it could also allow developers to inspect the metadata and pull out useful info like the regEx string which we could use to hook up our own custom RegEx validator.
Also, is there any way to have Breeze include the value of the ErrorMessage validation attribute property in the metadata and then have the breeze client use that instead of the default required and maxLength messageTemplates? This would mean you would only have to define the error message in one place on the server and wouldn't have to customize it for each entity.
I'm trying to avoid having to create and register a bunch of custom validators on the client for what seems like basic validations that could be handled by Breeze automatically.
Thanks,
Richard
It's a great question.
We haven't yet done a good job of documenting how the server serializes metadata but this should be coming "real soon now". However, if you take a look at the json coming over the wire you'll notice that validators are serialized simply by name. This name is then looked up among the registered validators ( or validator factories) on the client and then added to the client side metadata. So the idea would be to register you validator "implementation" on the client with a unique name, and then have the server reference this name when sending metadata down from the server.
Hopefully this will be clearer in a week or so once we have documented how to create your own server side metadata to send down to the client.
Hmmm, one year has passed. Any news on this topic? I fully agree with RWHepburn that defining all validation rules on the server-side and have it available in breeze on the client side would be a perfect thing. This is what data annotations in EF are for - making it easier!
With ServiceStack, I'm looking for ways to access related services by composing the URLs in a manner similar to OData.
An OData example would be a URL like
http://localhost:8080/owind.svc/Categories(2)/Products
This would find all the Products related to Category 2.
An equivalent example with ServiceStack seems to be that you would create a Request DTO for a ProductService and set up Routes something like this:
[Route("/Products")]
[Route("/Products/{Id}")]
[Route("/Categories/{Category}/Products")]
public class Products
{
public string Id { get; set; }
public string Category { get; set; }
}
(Ignore the separations of concerns issues mentioned here, the above attributes at least give a clear idea what I'm asking.)
And then in the ProductService you'd support finding Products either via the primary or foreign key. I see something along these lines used in the Northwind.ServiceModel.Operations.Orders class of the ServiceStack.Northwind.ServiceModel sample project.
So I'm wondering, is this the best and most scalable way that exists to do this sort of thing in ServiceStack, or is there some shortcut I'm missing? Thinking on a scale of creating services supporting hundreds of tables, if there existed some sort of shortcut, and if it didn't come with strings attached, it could be helpful.
I can imagine a system where you could automatically generate routes based on anything in a DTO, though you'd need to do some mapping from DTO property name (usually singular) to route (often plural).
No idea if it would be conceivable to carry this beyond one level either...for example
.../Employee/1/Orders/Customers
which would get you every Customer who has had an Order with Employee #1. The notion of implementing this manually on a large scale seems prohibitive. Not sure if there are SOA arguments to be made for or against, but that would be nice to know as well.
Just to be clear, there should be no assumption of the underlying data store or access libraries.
So I'm trying to figure out how to handle duplicates, and one way I thought of is like redesignating the type to the same type
eg
public class Employee
{
public int Id {get;set;}
public string Name {get;set;}
public int? RemappingId {get;set;}
public virtual Employee Remapping {get;set;}
}
so, basically, anyone can register but since I can't do any validations on this part if somebody accidentally saves a duplicate Employee, I plan to have some admin page to map the duplicate employee to like a "main" employee.
But I'm getting this error:
unable to determine the principal end of an association between the
types the principal end of this association must be explicitly
configured using either fluent API or data annotations
So I'm not sure if that's the right way of dealing with duplicates, if not please do point me to the right direction. And if it is acceptable, any chance you can help me stop the error?
Thanks!
Much appreciated!
So I'm not sure if that's the right way of dealing with duplicates : Yes, it really is not a good way to do it. and you know it too :)
How I would suggest you do it
As you are working with "Employees" I am assuming there will be some id which will be unique to the Employee, (like an EmployeeID). So by making such an id as a primary key, you can do a simple ifExists check for this and show a appropriate message on the view.
Update :
If there is nothing unique for an employee(not even email or employeeId etc), then according to me your database design is faulty. But that again is my personal opinion.
Hope this helps.
I have a modeling question related to profiles. Firstly, I have looked into using the SQLTableProvider and using the in built profiling system but didn't feel they were suitable. So, with that said, I have a membership scheme where every person has a profile, then that person can upgrade their profile to either an individual (additional fields) or a company account (additional fields again).
So I thought, use a Profile base class and then inherit from that for the Company account and Individual account. However, when it comes to implementing this in MVC I'm hitting a brick wall.
Since either the company or individual edit pages are effectively updating both the base Profile table and also the individual/company tables from the same page. How would I go about implementing this within the model (which is currently generated via LinqToSQL) and also at the view level?
Apologies if that wasn't very clear, tricky one to explain!
If you are using Linq to SQL, then you already have a model. Linq generates the entities and collections based on your database for you. The generated model is a shallow one, but is pretty solid and workable. The Linq to SQL model can be extended via partial classes allowing you to enhance entities or the context itself for additional functionality.
The controller can work directly against the generated model and pass entities or collections of entities to the view as needed.
I would suggest that, for what you appear to be trying to do, you might consider not using the built-in profile provider system at all. The profile providers in asp.net work well for simple personalization stuff, but it doesn't work well for concrete data like contact info and such. Also keep in mind that the profile provider systems tend to store object data as serialized strings in the database... this makes getting at profile data very difficult from admin tools and such. Performance starts to become a problem VERY fast in any case where you are needing multiple user's profile information (such as with an admin user editor).
For a when you are storing important personal details like the stuff you mentioned, what you are really storing are "account details" not "user profiles". You can extend a membership provider to expose your additional details, but I've generally found it much easier to just roll my own data model and access logic to deal with the additional account information.
My rule of thumb is this: if the information is ONLY needed during a request made by the user to whome the data belongs, then it goes in profiles. If I would need the data for one user to be read during another user's request, or if I would need a "list" of that data for different users, then it doesn't go in asp.net profiles.
Do you mean settings like choosing how many items to view on each page, and choosing some style sheet?
public class Profile
{
int? ItemsPerPage { get; set; }
string PreferredStyleSheet { get; set; }
}
The company selects some values that will work for users unless the users have chosen some other values for themselves. Is that what you have in mind?
In that case: I don't know how to do it together in ASP.NET Profile, but how about the following tables in the database:
TABLE Setting
(
SettingID int NOT NULL,
SettingName varchar(32) NOT NULL,
DefaultValue nvarchar(128) NULL
)
TABLE CompanySetting
(
CompanySettingID int NOT NULL,
RefSettingID int NOT NULL,
RefCompanyID int NOT NULL,
SettingValue nvarchar(128) NOT NULL
)
TABLE UserSetting
(
UserSettingID int NOT NULL,
RefSettingID int NOT NULL,
RefUserId uniqueidentifier NOT NULL,
SettingValue nvarchar(128) NOT NULL
)
And then make some joins for the present user. If the user setting is not given, take the company setting; if the company setting is not given, take the default value.