Download Free Demos

Identifying Users. Authorization

The library gives you the possibility to secure your application and differentiate permission levels for users.

scheduler authorization

Here is a common client-side authentication technique:

  • Check whether the current request has been authenticated (use the HttpRequest.IsAuthenticated property);
  • Get details of the currently logged in user;
  • Set appropriate permission level(s).

To make your application more secure, you can repeat checking on the server side

Permission Levels

The enumeration DHTMLX.Scheduler.Authentication.EditModes contains all the possible permission level values, which are:

  • FullAccess - the full access to all operations.
  • AuthenticatedOnly - just the authenticated users can create and modify events.
  • OwnEventsOnly - a user can edit just self-created events.
  • Forbid - a user can't modify events. Scheduler is running in the read-only mode.

Client-side Authentication

The code below is an example of the client-side authentication. You should define the client-side authentication in the action that initializes, configures scheduler and returns the main view.

public ActionResult Index() {
  var sched = new DHXScheduler(this);               
  ...
  if (Request.IsAuthenticated) {
     var user = context.Users.SingleOrDefault(u => u.UserId == (Guid)Membership.GetUser().ProviderUserKey);
     sched.SetUserDetails(user, "UserId", "user_id");
  }
  sched.SetEditMode(EditModes.OwnEventsOnly, EditModes.AuthenticatedOnly);
  ...
  return View(sched);
}

A few notes about the above code:

  • The GetUser() method of the Membership Class allows us to get UserID of the currently logged in user.
  • To determine whether the current request has been authenticated, the HttpRequest.IsAuthenticated property is used.
  • The SetEditMode() method sets user rights.
  • The SetUserDetails() method passes details of the current user (in JSON format) to the client side. The method takes 3 parameters:
    • The name of the object containing the user's details. This object is passed to the client side and stored in Scheduler.CurrentUser.
    • The name of the property that holds the id of the current user.
    • The name of the task(event) property that will be compared with the id of the current user to check whether the task(event) was created by this user.

Server-side Authentication

The code below is an example of server-side authentication. You should define the server-side authentication into the action that retrieves and saves data, and determines that the response can be sent back to the client (CRUD logic).

public ContentResult Save(Event changedEvent, FormCollection actionValues) {
    var action = new DataAction(actionValues);
    if (this.Request.IsAuthenticated && changedEvent.user_id == (Guid)Membership.GetUser().ProviderUserKey)
    {
       // your CRUD logic 
    }
    else
    {
       action.Type = DataActionTypes.Error;
    }
    return (new AjaxSaveResponse(action));
}

Was this article helpful?

Yes No