Implementation of authorization based on tenant information

Implementation of Authorization

Implementation of comment limits based on pricing plan units of measure

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 does that user belong to, what role does that user have, which price plan is selected by that tenant, and what menu can be used? It is in a state that can be obtained from the application. We will use that information to limit the application.

For now, let's focus on "Comments", which is part of the unit of measure in our 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

I am doing the setting.

Now, let's get the maximum number associated with this price plan for each tenant and set a limit.

Now, let's 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, we check the maximum number of comments based on the comment count target meter “comment_count”.

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

So in code,

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 price 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 rate plan is exceeded.

In order to simplify the process this time, I will limit myself to the fact that writing cannot be performed, but in reality I think it will output an error message or a message prompting an upsell.

However, 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 like this time, and it becomes impossible to write completely there, this will not work as a chat.
If you do, this SaaS may go unused until this meter is reset.
Of course, there is also the possibility that it will never be used again.
Therefore, instead of stopping it completely, it is important to prevent the value of this SaaS itself from being lost, such as issuing a warning even though it can be written, or adjusting the storage period.

Since this is a tutorial, I made it completely unwritable. Now, let's try to see if writing is not possible at the upper limit!

First, let's 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.

I think I have confirmed that I can only write up to 10 records.

Next, let's 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 after changing the setting.)

I think I am now able to write.

In this way, it is now possible to meter and limit according to the rate plan!

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