I'm testing periodic fee subscriptions in DNN 5. I've set the renewal period on my custom role to 1 day.
After 1 day, the subscription shows as EXPIRED, but the user can still view all the pages accessible to that role.
Am I missing something?
Apparently, DNN checks the subscription expiration time on the WEB-SERVER, and "view permissions" on the DB-SERVER.
I changed the date on my web server so I didn't have to wait for 1 day for the role to expire. As soon as I changed the date on the DB server, I wasn't able to view the pages any more.
Related
I am setting up subscriptions to M365 mailboxes so I can receive a change notification event when something happens to that mailbox. This has been working fine until recently when I started receiving this error:
Status Code: 429; Reason: Resource 'SubscriptionCountReached' has reached limit of '1000'. Please retry after '12/31/9999 11:59:59 PM
Ideally, I just want to delete all subscriptions setup on my M365 tenant, but cannot find where these exist in the Portal UI.
Does anyone have any ideas on how to clear out the old subscriptions that seem to be hanging around?
Status Code: 429;
Reason: Resource 'SubscriptionCountReached' has reached limit of '1000'. Please retry after '12/31/9999 11:59:59 PM
The above error usually occurs when you reach the maximum quota of times(1000) that are predetermined.
According to this Microsoft Doc, the maximum subscription quota for Azure AD resources are as follow:
To delete all the subscriptions set up in your M365 tenant, try steps mentioned in below link:
Delete subscriptions of Azure AD tenant - Azure Active Directory | Microsoft Docs
To allow deletion, subscriptions must be in Deprovisioned state.
An Expired or Canceled subscription will initially move to the Disabled state, and the final stage is the Deprovisioned state.
The simple way to cancel your subscription is to turn off recurring billing option in order to prevent other charges.
If you added your own domain name to use with your subscription, you must remove the domain before cancelling subscription.
The expired subscription will send several notifications. It can be deleted automatically after 90 days and will be deleted no later than 180 days.
For more in detail, please find below links if they are helpful.
References:
azure - Microsoft Graph. Exception : reached limit of '1000' - Stack Overflow
Cancel your subscription | Microsoft Docs
Delete expired subscription - Microsoft Community
Non-technical person here 🙋♂️
I'm having an issue where (using the Oauth 2.0 Playground) I authorize an internal user's GMB account and configure real-time notifications to be sent to our GCP topic. Every few days or so, notifications stop getting sent to our topic and when I check the notification settings for that account, they have been subscribed to an unknown GCP topic. I can reconfigure the notifications settings again, but every few days they are reconfigured to the unknown GCP topic.
It's possible some other app is overwritting my changes periodically, but I am having trouble figuring out where they're coming from.
Is there a log I can review to know where the request to change the notification settings is coming from?
When using the OAuth 2.0 Playground to configure settings, do they "expire" at some point? If so, is how do I prevent that from happening?
Thanks in advance for your help!
You can start looking into when and who created the unknown GCP topics by checking your Cloud Logging for created topics. You can do this by:
Open your Google Cloud Console
Open "Logging"
There should be a "Query" tab and select it.
Input protoPayload.methodName="google.pubsub.v1.Publisher.CreateTopic" and click "Run Query". You can check this reference if you'd like to see other logs related to Pub/Sub.
Click "LAST 1 HOUR" to adjust the time parameters of your log query. (Example: adjust it to a whole month to query all Created topics within a month)
Click the ">" beside the result and expand the log.
There are lots of info like the created topic name, what email authenticated this request, etc. In your case you should look out for field authenticationInfo for you to check who invoked the request:
authenticationInfo: {
principalEmail: "email-used-to-create-the-topic#example.com"
principalSubject: "user:email-used-to-create-the-topic#example.com"
}
NOTE: For testing purposes I blacked out my project-id and email for this example. Also the topic I created is log-this-topic and the email in the log mine since I was the one that created the topic.
OAuth have set rules for expiration, you can check it on Refresh Token expiration.
I am trying to delete a free trial of AzureAD but there are two requisites that I am unable to get past these are
Delete all licence-based subscriptions
Delete all azure-subscriptions
When you click on the first option this states there are no subscriptions to delete?
If you try the second option and navigate to the trial there is no cancel option as this trials status is set to disabled?
Anyone know how to proceed so I can get this test AzureAD account gone?
To delete a directory in Azure Active Directory, you need to meet all the checks.
Azure trial subscription will be canceled automatically after the trial. But you cannot delete the subscription yourself. You will need to wait 90 days before permanently deleting your data in case that you need to access it again.
Here is the reply from MicrosoftDocs.
You can't delete an Azure subscription directly. As the article
states, all an account admin needs to do is Cancel subscription.
Billing stops at that point and all Azure services get disabled, but a
final invoice isn’t created until the end of the current billing
period. 90 days after you cancel the subscription, Azure automatically
permanently deletes the subscription and all data.
Reference:
Can not delete subscription
Add an option to delete disabled subscriptions
Please help me architect the following case in Laravel:
Every instance of the Laravel app (ex. a company) will have a single username (super-user) who can control the sub-users. The super-user will log into the app once to allow the sub-users to log in and out many times throughout the day. The sub-users won't be able to access the app at all without the super-user logging in.
Example: A POS system that the manager logs into once a day. It doesn't log itself out all throughout the day. The cashiers simply tap in their password to gain access and it auto-logs out after 5 mins. There's a single system in the store so the cashiers have to keep switching on and off. The cashier wont be able to use the POS at all if the manager does not log in.
Im new to Laravel. I know I need multiple guards but how do I access auth so that it doesn't keep directing me to the super-user? Im thinking of using the default laravel authentication for the superuser. But what about the other users?
Any help or pointers in the right direction is highly appreciated!
Thanks!
Laravel cannot persist multiple authenticated users at once but you don't necessarily need that for this system, in fact you may be able to design a more robust system without it.
Defining the problem (rather than a solution) we'd say something like, "The system must allow for a manager to enable and disable the POS for cashiers so that they are only able to access it when authorised".
A system that achieves that goal can be built with a single Laravel authentication system, using different roles (manager, cashier) and the associated permissions. This is (fortunately) very straightforward with Laravel.
The user flow would be along the lines of:
A cashier visits the POS terminal
The cashier clicks "log in"
The cashier enters their identifying details
The system finds the user, identifies that they're a cashier, then checks if cashiers are allowed to log in
If yes, the cashier is logged in and able to access the POS functionality
If no, the cashier log in is rejected with an error
The manager flow would be along the lines of:
A manager visits the POS terminal
The manager clicks "log in"
The manager enters their identifying details
The system accepts their log in and sends them to the management dashboard
The management dashboard would be where the manager could control other users (create and manage cashiers (edit, delete, audit)) and set the system status as activated for cashiers, this would be protected with policies.
At the start of business the manager would log in to the POS and activate it for cashiers by setting the "active" flag to true, then the manager would log out. Through the day any cashier could log in and use it. At the end of the day the manager would log in and deactivate the POS for cashiers.
An added benefit of this system is that you could allow managers to also be cashiers so if they needed to use the POS during the day they would not need a separate account. A users manager status could be a simple is_manager database column. You could additionally implement programmatic scheduled POS availability, i.e: "allow log in from cashiers between 9am and 5pm".
Laravel is a great choice for this project as it provides everything you need out of the box, let me know if you have any other questions about your implementation :-)
For a calendar app, I want to sync users calendars (events) to my database. For now, I need title, start, end, recurrence and reminders/alerts. I am thinking, I will get these information from app and store it to a database. To make things easy (implementing recurrence maybe hard), I thought of using a hidden Google Calendar account on the server as a database.
Server will use a "hidden" Google Calendar account
App (iOS) will get calendar information from user's iCal via EventKit
Passes server this information which is saved to Google Calendar
So 1 user calendar becomes 1 hidden google calendar
But I think I might encounter some problems with API limits?
I might need to re-authenticate to refresh the access token? Is there a token I do not have to refresh?
Is the limit on the number of calendar I can have 10,000? What if I need more? Isit even possible? Or is it 10,000 for "a short period of time".
Is this possible? Or is the only option a self build system.
The quota for the Google calendar API is Queries per day 1,000,000 if you go over that you can always request additional quota as far as I know it doesn't cost anything to extend your quota.
Once you have authentication to a user Google calendar account you will receive a refresh token. The refresh token can be used to gain a new access token when ever you need to access it. Refresh tokens don't expire unless a user removes your access.