Implementation of authorization based on tenant information

Suggest Edits

Implementation of Authorization

Implementation of comment limits based on pricing plan measurement unit

Let's modify the previous sample application and implement the first step of authorization.

With the SaaS Platform settings so far, which user is logged in, which tenant the user belongs to, what role the user has, which price plan is selected by that tenant, and what menu can be used? can be obtained from the application. We will use that information to limit the application.

For now, focus on "Comments", which is one of the measurement units in the pricing plans.

Earlier, we set a different upper limit for the number of comments for each price plan.

  • 10 comments limit on Free plan
  • 100 comments limit on Basic plan
  • No limit on Advanced plan and above

Now, get the maximum number associated with this pricing plan for each tenant and set a limit.

Rewrite the post method of api/app/Http/Controllers/MessageController.php as follows.

   public function post(Request $request)
   {
        $validated = $request->validate([
            'message' => 'required|max:255'
        ]);

        $tenant_id = $request->userinfo['tenants'][0]['id'];
        $plan_id = $request->userinfo['tenants'][0]['plan_id'];

        // Use the SaaSus SDK to hit the SaaSus API, acquire various information, and use it for judgment
        $client = new \AntiPatternInc\Saasus\Api\Client();
        $pricingApi = $client->getPricingClient();
        $res = $pricingApi->getPricingPlan($plan_id, $pricingApi::FETCH_RESPONSE);
        $plan = json_decode($res->getBody(), true);

        // use metering meter, comment_count
        $meteringUnitName = "comment_count";
        $res = $pricingApi->getMeteringUnitDateCountByTenantIdAndUnitNameToday($tenant_id, $meteringUnitName, $pricingApi::FETCH_RESPONSE);
        // This time, treat it as the maximum number of comments per day
        $count = json_decode($res->getBody(), true);

        $upper = \AntiPatternInc\Saasus\Api\Lib::findUpperCountByMeteringUnitName($plan, $meteringUnitName);

        // Disable posting if the number of comments exceeds the maximum number of comments for the current contracted price plan
        if ($count['count'] < $upper || $upper === 0) {
            $message = Message::create([
                'tenant_id' => $tenant_id,
                'user_id' => $request->userinfo['tenants'][0]['user_attribute']['username'],
                'message' => $request->message,
            ]);
            // add 1 to the number of comments in the metering API
            $param = new \AntiPatternInc\Saasus\Sdk\Pricing\Model\UpdateMeteringUnitTimestampCountNowParam();
            $param->setMethod('add');
            $param->setCount(1);
            $res = $pricingApi->updateMeteringUnitTimestampCountNow($request->userinfo['tenants'][0]['id'], $meteringUnitName, $param, $pricingApi::FETCH_RESPONSE);
        }

        $request->session()->regenerateToken();
        return redirect()->route('board');
   }

In addition to the previous code, check the maximum number of comments based on the comment count target meter “comment_count”.

Earlier, the measurement unit is set based on “comment_count” in any price plan measurement unit as shown in the screen below.

In the function,

Get the price plan associated with the tenant,

Get the current value of the target meter “comment_count”,

Checking the upper limit of the upper limit "comment_count" associated with the pricing plan

and if the current value does not exceed the upper limit,

Do the comment writing process as usual,

Add 1 to the current value of the target meter "comment_count" and update.

By doing this, it is possible to prevent writing when the upper limit for each pricing plan is exceeded.

In order to simplify the process this time, the program will be limited to stopping additional comments once the maximum number is reached. However, in a real case scenario an error message or a message prompting an upsell should be displayed.

Depending on the function, if it is completely stopped at the upper limit, the value of SaaS may be impaired.
For example, if we put an upper limit on comments, and it becomes impossible to write completely there, this will not work as a chat application.
Resulting in this SaaS may going unused until this meter is reset, also taking the risk that there is also the possibility that it will never be used again.
Therefore, instead of stopping comments completely, it is important to prevent the value of this SaaS itself from being lost, such as issuing a warning about the limit, or adjusting the storage period.

Since this is a tutorial, it is completely unwritable. Now, check to see if writing is not possible at the upper limit!

First, run init.sh to clean up the application, just like when we first initialized the application.

Then, set the Free plan for Tenant 1, log in with [email protected], and write 10 or more items.

This shows that tenant 1 can write a maximum of 10 records.

Next, log in with user [email protected] in tenant 2 and write 10 or more items.

Since the upper limit is 100 here, you should have been able to write more than 10.

Furthermore, assuming that tenant 1 has upgraded the plan, change the setting from the Free plan to the Basic plan, log in again with [email protected], and write 10 or more items. prize.
(It takes about 5 minutes to reflect the changed settings.)

This shows that user1-1 can write more than ten items.

Using this method it is now possible to meter and limit according to the pricing plan!

Up to this point, we have implemented Blade-based applications, but finally, how should we implement Next.js (API-based SPA)? Let's continue.

Updated 6 months ago

What’s Next