Base solution for your next web application
Open Closed

Create custom session to store user specific data #7189


User avatar
0
sumitshah created

We have migrated to the latest version i.e. v7.0 and using the Angular-.net core template.

Just like we can create custom sessions in asp.net web forms eg. Session["UserSpecificStates"] = "New York, Alabama", we want to create similar session/ claims in aspnetzero.

There is no proper documentation available for custom claims/session in abp.

Can anyone please share how this can be implemented.

Thanks in advance.


8 Answer(s)
  • User Avatar
    1
    maliming created
    Support Team

    hi

    You can refer to: https://aspnetboilerplate.com/Pages/Documents/Articles\How-To\add-custom-session-field-aspnet-core https://gist.github.com/ismcagdas/6f2a9a3b5d7b907cb8d94a72124d59a1

  • User Avatar
    0
    sumitshah created

    Thank you for the prompt reply.

    Does using the claims have any limitations. So to be precise how many claims can be added and also is there any limitation to no. of values added to a particular claim.

    For example:

    1. I create additional 20-30 user specific claims which maintain different user specific data. Is this possible?
    2. In a specific claim can I store a long string. Any limitation to no. of characters to be stored in a claim?
  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @sumitshah

    1. I think this is possible but it is suggested not to store too much data using claims. What kind of data do you want to store on claims ?
    2. That is also not suggested I guess. It is better to find another way if you need to store too much or big data in claims.
  • User Avatar
    0
    sumitshah created

    So below is the exmple I am talking about:

    I have created a claim by fetching user specific records from the custom repository:

    public override async Task<ClaimsPrincipal> CreateAsync(User user) { var IdmsUserId = _userRepository.GetUserIDByUserName(user.UserName); var DatabaseIds = _cmpRepository.GetDatabaseIdByUserID(Convert.ToInt32(IdmsUserId));

            var claim = await base.CreateAsync(user);
            claim.Identities.First().AddClaim(new Claim("Application_UserName", user.UserName));
            claim.Identities.First().AddClaim(new Claim("Application_IdmsUserId", IdmsUserId));
           ** claim.Identities.First().AddClaim(new Claim("Application_IdmsUserDatabaseIds", string.Join(",", DatabaseIds)));**
            return claim;
        }
        
    

    The records returned is a comma separated string of number:

    1138,936,937,1002,935,1003,515,1216,1160,299,158,1035,954,1168,1075,404,561,73,426,423,778,429,228,838,839,1045,771,576,542,164,167,156,165,168,152,166,169,529,710,624,649,641,941,828,482,605,993,915,899,596,907,735,913,300,564,964,268,84,376,1008,1006,559,842,843,956,82,74,215,213,727,917,767,502,978,351,441,332,458,290,1101,1062,288,470,1175,1025,465,1110,472,852,933,725,840,841,1206,829,399,627,694,414,825,463,955,179,273,187,386,279,250,188,192,173,174,189,258,875,265,367,295,873,871,362,364,277,193,874,175,249,390,449,190,194,257,868,255,176,254,354,263,291,280,296,177,260,373,178,248,191,245,274,359,355,872,264,271,256,869,363,276,278,262,287,870,70,358,85,930,1020,670,620,642,910,1121,1052,1233,1200,195,1038,537,1016,1029,1015,740,1066,427,1026,382,86,853,1067,221,222,1162,846,1135,149,892,1240,1126,783,581,66,830,658,1223,1222,764,755,1142,408,1207,1208,509,612,530,686,958,1037,253,1209,754,1082,650,478,1196,1119,656,521,990,901,957,87,881,880,905,416,984,88,1128,601,995,739,719,632,1241,387,89,756,619,75,1048,1078,705,1024,948,444,302,289,361,217,90,330,224,324,980,91,391,675,1011,593,821,527,591,592,543,522,971,440,92,577,578,413,611,1120,318,952,1086,285,93,665,313,879,604,1118,94,401,328,634,1093,614,688,681,1097,452,1053,471,418,445,385,368,372,395,171,377,392,1177,603,717,422,476,1040,1041,76,882,883,884,885,886,366,887,690,953,1218,283,858,95,1099,1153,1159,900,706,96,1023,97,98,199,1065,1059,563,1150,950,831,282,99,1193,1060,1192,898,703,77,773,748,1170,421,966,709,716,473,100,744,1030,487,701,949,697,101,1088,102,468,103,647,663,704,693,602,329,565,1111,1157,1179,1180,1181,1182,1183,1184,1185,1164,1187,1188,1166,1189,1167,1190,1269,1191,1270,1271,1272,1273,1274,1275,1250,1251,1252,1253,1254,1255,1256,1257,1258,1242,1243,1244,1245,1246,1247,1248,1259,1260,1261,1262,1263,1264,1265,1266,889,317,311,1149,431,1005,651,512,104,425,105,495,497,513,409,726,503,1198,733,1009,106,246,269,267,356,185,186,435,107,251,201,108,982,908,774,770,769,648,600,850,970,931,1004,1007,1130,940,1032,396,1195,1019,551,555,548,550,549,545,547,546,553,552,109,389,293,286,180,182,181,183,378,1098,554,492,491,417,150,336,345,334,1132,1018,897,1012,757,687,1229,1107,1268,803,804,805,806,807,808,809,810,811,812,813,814,815,816,817,845,994,1074,1100,1178,1034,247,110,111,474,398,459,112,751,1113,1096,1108,402,113,172,114,963,962,961,925,214,860,1151,430,1176,730,198,357,1267,992,443,424,72,752,301,1171,1103,789,796,788,795,791,786,790,797,798,793,792,787,799,785,794,210,157,155,163,1210,1134,370,115,270,337,594,69,878,595,877,154,947,320,1044,997,1221,1220,303,1010,1219,218,116,184,481,1137,1146,489,501,360,446,973,895,523,1087,507,1022,991,455,854,233,654,1227,200,700,308,691,896,698,903,517,498,779,780,781,1051,1122,1123,220,638,1070,635,985,205,322,348,488,1061,412,1249,212,117,713,558,768,746,118,597,587,510,496,666,776,608,724,79,1069,1071,1072,1213,1144,275,227,223,81,196,447,393,975,338,307,153,1136,960,1031,1000,119,1095,479,847,1114,1115,1145,621,1143,454,439,306,645,420,240,120,1203,252,352,374,618,731,636,315,556,800,1036,999,662,206,346,226,653,347,508,533,1076,394,121,765,579,573,536,1063,211,921,922,932,1201,494,660,1057,1224,1225,582,782,1039,607,1021,540,722,1073,659,1055,1056,1228,572,855,122,944,943,945,1133,381,123,610,616,407,159,720,801,124,125,633,500,1173,485,622,126,272,281,266,294,297,365,451,284,369,170,298,219,162,1154,1083,888,127,128,490,904,833,738,689,996,669,682,673,683,1211,766,574,519,400,824,668,680,671,685,676,679,678,677,586,590,585,588,761,628,1235,411,1106,923,906,525,160,325,350,349,919,918,562,316,419,981,1197,532,379,83,434,569,1054,331,225,321,534,524,938,341,674,667,655,1102,457,715,609,639,613,646,580,707,802,207,1236,1231,867,388,129,460,643,661,1155,979,977,976,836,837,934,1050,437,259,375,438,834,835,1091,1092,969,1027,353,456,333,342,415,1080,68,161,864,865,863,1085,1033,514,974,539,528,216,1215,1068,606,1125,1129,728,130,862,1161,1169,866,292,927,924,1105,1199,1081,1084,506,131,848,1094,1232,466,987,78,326,462,132,442,986,640,775,652,1077,1089,911,499,566,309,484,891,1230,1147,1148,133,818,623,340,403,1226,1234,518,1239,323,80,859,861,711,71,204,1058,714,405,989,1156,134,344,699,849,135,384,617,136,511,692,137,737,505,538,305,310,410,599,723,928,598,695,567,208,371,261,939,914,138,729,480,1194,575,1158,1047,1124,763,664,762,734,772,929,998,1028,570,520,209,946,383,721,1237,1238,557,1109,202,433,139,197,784,1204,1205,926,644,1116,436,453,732,696,140,876,916,1013,583,1042,1043,428,1104,1131,1049,141,1079,304,902,983,851,760,684,486,464,335,475,826,467,959,450,380,448,1212,750,967,968,758,339,844,736,397,469,560,827,972,965,822,745,637,142,1064,1090,909,1163,65,893,894,988,314,920,1127,718,143,857,144,1141,319,630,568,1017,1014,629,615,327,1046,1172,672,1174,461,1217,777,1112,942,203,145,1214,747,708,626,432,759,749,477,1139,1140,1117,406,1165,1202,631,312,1186,1276,657,1001,1152,890,741,531,625,343,856,819,504,912,146,493,483,820,823,712,832,571,541,516,148,234,242,232,241,236,230,235,243,244,238,237,231,229,239,753,702,742,544,535,743,526,589,584,147

    If the string is this big, am not getting any error but the user is re-directed to the login screen. I checked the logs, even added multiple breakpoints but not able to catch the exact error.

    Whereas if the string contains less numbers, the system works as desired.

    So are there any limitations of storing data to claims,

    Also, can we use .net core session to store these values. There is no proper documentation for how to user IAbpSession to store custom sessions. Can someone share the implementation of using custom sessions.

  • User Avatar
    1
    maliming created
    Support Team

    If the string is this big, am not getting any error but the user is re-directed to the login screen. I checked the logs, even added multiple breakpoints but not able to catch the exact error.

    maybe the size of the request headers is too long. There may be an error of http 400 in the log.

    I suggest you put this data in the cache, and then query according to userid and so on.

  • User Avatar
    0
    sumitshah created

    Thank you for the suggestion. We have implemented entity caching for particular set of data required across the application, irrespective of users and is working fine.

    But now, we require to cache user specific data so we are planning to implement as below:

    1. On user login, create multiple cache as per the requirement(need to store multiple and different records from different database tables)
    2. The cache will have unique name by appending userid to the cache name
    3. While using the cache across the application, to retrive the value we will again append the cache name with the claim userid and retrive the values
    4. When the user logs out we clear all the cache related to that user again by appending the cache name with userid

    Has anyone implemented session using caching in the above mentioned way?

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi,

    I'm not sure if anyone else did this but it is possible. You can use https://aspnetboilerplate.com/Pages/Documents/Caching to cache data. Just don't forgot to include Current Users TenantId and UserId in the cache key.

  • User Avatar
    0
    sumitshah created

    Thank you!! we are in process of implementing distributed caching using Redis. We have on premises servers so will be setting up Redis server on one of the windows on premise server using chocolatey redis