I'm trying to set up Satchmo, and I found this cool Subscription Product, but what I want is make a members-only section on the site (a multiple store website) itself. In other words, I want the users to make subscriptions to be able to use certain features. Is this possible in Satchmo?
I guess if my website is called xyz.com then I can create xyz store on the system and let it have a subscription product, but can I integrate it with the Django login system?
Thanks in advance.
You can listen to satchmo_store.shop.signals.order_success and include in your listener all the required steps for self subscription (user to group, object creation etc.,..).
Related
For audit purposes I'm trying to revoke/remove all blocked users from groups using a Python script. Until now I managed just to list all blocked users in my Gitlab instance using a simple curl:
curl -H "Private-Token: xxx” https://mygitlab.domain.com/api/v3/users?blocked=true. Can anyone point me to the right direction for a list with the groups, blocked users\group and how to revoke them using Gitlab API and Python. Any suggestion would be appreciated.
Thanks
I will give you a path to follow what you want, because stackoverflow is not a scripting service.
I don't how you are comfortable with scripting
Some tips to follow
List all groups
For each group, list all users
List all blocked users
Remove/Revoke every user of each group
This is the basic of your script, in this order
The next step is related the language that you want to use, in this case, python
I don't know if you know how to make http requests with python and, if not, read this article
https://rapidapi.com/blog/how-to-use-an-api-with-python/
This kind of audit is part of a larger effort followed by Epic 3155: "Provide an audit report of user permissions by group and project"
This is being implemented with, as a first step, GitLab 13.12 (May 2021)
Added total group and project count to admin users table
Previously, it was difficult to know how many groups and projects a user belonged to. Compliance-minded organizations, in particular, want to know which users have access to what systems or resources as part of their access management policy.
This information provides visibility into your users’ memberships to know if a user has too much access, may have leftover access from a change in their role or employment, or help you determine the scope of a user’s involvement in your company’s projects.
Now it’s easier to get a high-level view of your users’ memberships for auditing purposes.
In this iteration towards an exportable user access report we’ve added additional data to the admin panel for self-managed instances to show the total number of groups and projects a user belongs to.
See Documentation and Epic.
And:
See GitLab 13.12 (May 2021)
Users' group counts now displayed in Admin Area
The user list in the Admin Area now shows the total number of groups
a given user has access to. The group count is a sum of both group and subgroup membership.
This is incredibly valuable,
because you can easily see how much access users have and quickly
identify when action is needed.
For example, you might use this information
to ensure that deactivated accounts no longer have access to any projects or
groups in GitLab.
See Documentation and Epic.
How do I determine which type of account a person has when using the permissions api? I need to make a different decision if they have a pro account versus a standard business account. Thanks!
This can be be done using the Adaptive Accounts API and more specifically the GetVerifiedStatus call.
A successful response will include the UserInfoType Fields including the accountType which is what you're looking for.
You can find what a successful response looks like here, click on GetVerifiedStatus and fill in the blanks.
I'm not aware of any way to see that via the API. That's typically something you'd leave up to the end-user to know when they're signing up. Ask them if they have Pro or not, and based on that, setup your permissions request accordingly.
I plan to use Google Accounts to authenticate users of my GAE app.
As i understand it, all owners of a gmail adress are considered equal and can be authentified.
My app providing a free trial mode that requires no login, i'm only interested to authentify my paying customers.
Maybe I miss something, but the only distinction between users mentioned in the docs is between admins/non admins.
What is the common practice to authenticate a specific class of users (in my case: paying users) in GAE?
Have a look at gae-biolerplate, it shows how to create a user class using different logins
If you want to have extra information on users use a new model ie UserExtra to add information
like ie paid etc
link to boilerplate
Can you advice me with some articles/applications that allows you create SaaS(Software as a Service) application with Python and Django.
For the moment the general topics I do not understand are:
Do you have one working application for all clients or one app per client
How do you manage database access, permissions or different DB for each client
Are there any tools that allows you to convert one app to SaaS
one project, this will make maintenance easier. I handle host resolution with middleware in django-ikari.
you don't. see #1
I use the following :
django-ikari : anchored (sub)domains
django-guardian : per object permissions
django-tastypie : easy RESTful api
django-userprofiles : better than django-registration
django-billing : plan based subscription controls
django-pricing : plan based subscription definition
While not necessary, the following will help in the long run:
django-hunger : private beta signups
django-waffle : feature flip
django-classy-tags : nice, easy and neat templatetag creation
django-merchant : abstracted payment gateway framework
django-mockups : fast testing with models
django-merlin : better multi-step forms (wizards)
Finally, nice to have
django-activity-stream
A very basic, elementary example of how you would go about it.
Suppose you have a simple app designed to solve a particular business case. For example, you created an app to handle room reservations at your office.
To "convert" this app into a service you have to configure it such that most of the user-specific parts of the application are parametric (they can be "templatized" - for lack of better word).
This is how the front end would be converted. You might create variables to hold the logo, headline, teaser, color scheme for the app; allowing each user to customize their instance.
So far, your app is able to customize itself on the front end. It is still using the same database that was designed in phase one.
Now comes the matter of showing only those fields that are relevant to a particular user. This would be parameterizing the database. So you might add a column that identifies each row as belonging to a particular user; then create views or stored procedures that filter records based on the logged in user.
Now the application is able to be "rented" out; since you are able to customize the instance based on the user.
It then just gets bigger from here - depending on the scale, type and intended customization of your application. You might decide that your application performs better when each user has their own dedicated database instead of the stored procedure + view combo.
You may decide that for some user types (or "packages"), you need a dedicated instance of your application running. So for "premium" or "ultra" users you want to have their own dedicated system running.
If your application requires lots of storage - you might decide to charge separately for storage.
The bottom line is it has nothing to do with the language used. Its more an architecture and design problem.
Software as a Service is just a marketing word, it's technically no different from a server that is accessible over the internet. So question 3 makes no sense. That leaves us with question 1 and 2:
What do you mean with 'app' in this context? Your web application (built with Python and Django) can have multiple Django apps (components that make up the web application) but I think that's not what you mean. You can build your website in Python/Django and have various customization options depending on which user (client) is logged in. For example, a premium client can have several advanced options enabled but it's still part of the same codebase. It's just that some options (buttons/controls, etc) are not shown for certain clients
Django has plenty of tools for user management, permissions and groups. You can give each user (each client) different permissions and these permissions determine what they can do. Database access should be managed by your web application. For example, the code determines what information needs to be displayed on the webpage (depending on which client is logged in) and that code retrieves the information from the database. Depending on the scale that you're aiming for, you can also specify which database should be used to retrieve the information from.
I have a blog post describing my proposal of how to go about making a multi tenant SAAS web application using Django. Multi-tenancy here means that when user registers, they have their sub-domain. To recap:
All tenants share one database, but each has their own schemas. Imagine you have website abc.com and someone registered a xyz tenant so that they access their page through xyz.abc.com, then for a tenant xyz you have a separate schema containing all the tables thus encapsulating data related only to xyz tenant. There are other ways, like having one database and one schema for all, or having even separate databases. But schemas approach is the best trade-off. The django-tenants library's documentation contains more detailed info if you are interested
Use django-tenants library to abstract away work with tenants. When someone accesses xyz.abc.com, you need to know that xyz is the tenant and that you should use xyz schema. django-tenants library does this for you so on each request you can obtain the tenant object by simply doing current_tenant = request.tenant
You need to differentiate between shared tables and tenant-specific tables. For example, having table with list of orders is tenant-specific. Every tenant might have their own database containing all their orders. This table should be inside xyz schema. At the same time, you will have some core Django tables, like user. The data can be shared, for example, to disallow two users registering with the same email.
You need to configure your DNS to catch a wildcard expression *.abc.com, for which you can add an A record inside your CPanel with *.abc.com linking to the IP of your server
I'm trying to make a website that allows you to setup a photo gallery with a custom domain name.
Users of the site don't know how to register or configure domain names, so this has to be done for them.
User enters desired domain name in a box (we check if it's available) and click 'register' button and our website registers the domain name for them and sets up the website automatically (when user goes to that domain name, the photo gallery just works, no technical skills needed).
Enom has an API for resellers which could let you automatically register a domain on behalf of a user. (I have no affiliation with eNom, nor have I used eNom's products).
Implementation of *.weebly.com
Typically this form of dynamic sub-domaining will use a Wildcard DNS record. This type of record maps a wildcard pattern like *.example.com to one or more servers.
Let's say you have a blogging site and want to let users choose domain names dynamically. You put up a webpage on www.example.com with a form to let user's select names. So a user signs up and chooses bar.example.com.
Suppose your DNS server has the following mappings:
foo.example.com > 1.2.3.1
*.example.com > 1.2.3.2
Any request for foo.example.com will route to 1.2.3.1, but any other name, such as bar.example.com, will be served by 1.2.3.2. So when the user is redirected to http://bar.example.com the browser will hit 1.2.3.2. Note that since no DNS changes needed, there is no propagation delay: the redirect will work instantly.
The software running on 1.2.3.2 would then examine the Host header in the request, parse the fqdn and strip off .example.com, and resolve bar against a database. If a record exists, it will serve up the appropriate response for bar.
You'd also want to keep a list of reserved names or patterns you plan to use in the future, like www\d*, mail\d*, ns\d*, so that when a user tries to register the site www07 your blacklist will reject it.
Mapping any domain to bar.example.com
Once the bar.example.com site exists, the user may want to map a custom domain name like www.widgetsimakeinmyhome.com to their site. The registration and setup for this is mostly manual, and sites like EasyDNS make it pretty simple. Some registrars may have APIs to make part of this easier for you. These should typically be RESTful or at least HTTP-based APIs, so you can choose which client library you like to use (e.g. urllib2).
To create the mapping, your database would have a table mapping primary sites like bar to one or more domain aliases. A person would sign-in and map www.widgetsimakeinmyhome.com to bar.
Now your software needs to check the Host header against both the primary site table and the alias table to resolve to the correct site.
There is no general API for this. You have to check back with your own domain registration organization. This is specific to the related domain provider.
I would recommend http://www.zerigo.com/managed-dns ... a managed DNS api solution. I noticed this service existed when a large website provided mentioned something about them. I'm thinking about using them in my next project (similar setup to what you want) and using eNom for domain registration.
Usually you register a domain via a registrar. These companies often provide proprietary APIs which you can use to do this in an automated way. (Some registries also allow registration without using a third-party registrar, for example DENIC)
The registrar then orders the domain at a registry specific to the top level domain. For the communication between registrar and registry the Extensible Provisioning Protocol was created.
Some registrars also implement EPP as an API for their customers so in theory you could use this protocol and switch to another registrar without having to use a new API. I have not done this yet so maybe you have to make adjustments when you actually switch registrars.