I programmed a web app and now i need to deploy it for my organization. There are 500 potential users. What factors i need to consider before the deploy? There's an easy way to deploy it? there are limitations to consider? what risks there are? there are a model or can you give tips or experiences for the deployment?
There are no definable risks or dangers, it all depends on what your application does.
When you choose who are the users authorized to access, you will inevitably have to select anyone within your organization, otherwise only you (or the account with which the script was created) will be able to access. While as for the execution mode, you will have to choose how you or the user who accesses the application. This is important because if the application accesses an external service, such as Google Analytics, it can do so as the user with whom the application was generated or as the user who is accessing the application. Based on that selection you will see the Analytics data of one or the other Account.
So it all depends on what your application does and how it is to be used.
Related
I am working on a google workspace add-on for gmail. As part of it, I want to store and index some data, so that it can be later aggregated/enriched for insights.
I don't want to use some external(outside-google-workspace) database as it will have data privacy and security implications. So, I want to keep that data within the safe precincts of the user workspace.
Is there any database service within the google workspace for the above mentioned requirements?
PS: I am already aware of Properties service which can store configurations. The data i want to persist is definitely more than that.
There is no such database.
The closest alternatives, as already mentioned, are PropertiesService, which has obvious limitations, and Google Cloud SQL databases, which live in Google's cloud but is not part of Google Workspace.
I think I made a big mistake.
I was asked to investigate Office 365 vs workspace and took out a workspace trial. In hindsight, I probably should have created a new workspace account to try this.
To be clear for a long time we have had access to and used the "Google Workspace Admin console" purely to setup our organisation and adminster users for compute engine projects. I am not sure why we would have had access to this without a paid account. (possibly we used g-suite before. It's not clear to me whether companies are able normally able to access this without a paid account.) I assumed this was akin to the free azure organisation/user setup. Nowadays, I believe we would possibly be advised to use Google Identity in this situation.
Having taken out the trial I understand from workspace support that at the end they will delete my existing organisation and users; they cannot not switch me back to an "identity only" version of workspace we seemed to have before, and are therefore forcing me to sign every user up to workspace even though we don't need it at this point. Is this the case or are they advising me incorrectly?
Assuming they are correct, I cannot sign our company up to google identity, since our domain is owned by the soon to be deleted workspace account.
Therefore my worry is that my business is about to lose access to our compute engine organisation and associated logins, as well as google domains.
The only options I can see are to pay for workspace for our users every month, or create a new organisation in cloud identity, transfer the compute engine projects, wait for the workspace account to be removed, then reclaim our main domain and recreate all the admin users. (I am not sure whether we can move a project out of an organisation once there.)
Is this even possible, and what are the dangers? Are there any other options?
If you have a GCP organization and access to the Admin Console, you must have some subscription. You can see your subscription(s) in the Admin Console under Billing > Subscriptions.
It's possible to add or change subscriptions, but there are some restrictions: For example, if you currently have a G Suite Legacy subscription, you might not be offered the ability to add a Cloud Identity Free subscription. But there are ways to deal with this -- for example, by temporarily upgrading to a paid plan, and then switching to Cloud Identity Free.
Support should be able to help you find a way that doesn't require deleting and re-creating your account/org.
Johannes Passing is correct.
admin.google.com on the home page says "Welcome to the Google Workspace Admin console" - this is confusing since the portal is also about administering organisation and users through cloud identity as well (it could be better named for example "Organisation Admin console")
In addition, there are actually different answers from google:-
This one (which I originally read) says "If your trial period ends and you haven’t set up billing or verified your domain, your account will be automatically deleted" and also "You won’t be able to access Google Workspace after completing the steps."
https://support.google.com/a/answer/6388094
...but this one correctly says "Note that cancelling Google Workspace doesn’t remove user accounts, groups, or your organizational structure"
https://support.google.com/a/answer/1257646
Together this gave the impression that access to admin.google.com may be completely removed, if a subscription is removed. I can clearly see that I also have a subscription to Cloud Identity Free.
I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.
I was hoping someone could help me answer a couple of questions regarding Tableau. I am not as familiar with the platform, but I have a client who is looking for a reporting/analytics/data visualization platform that they could use for many of the internal apps (for their employees) and external (customer facing internet with login) applications.
The driver is that each of their internal teams has used many disparate technologies such as SSRS, Crystal, custom ASP.NET controls (Kendo/Telerik, etc), but now they have the opportunity to choose a common platform that could serve most/all of the future reporting and data visualization needs for enterprise and customer facing solutions.
They are looking for a platform that provides everything from simple grids with basic filter/sort/group, all the way to rich charting and ad-hoc reporting with slicing and dicing of data.
They will not always be creating dashboards in these apps since they are customer-facing, but they may want to have dashboards for internal (intranet) apps. They will definitely want the ability to build true internal BI dashboards to report on data from all these online apps across all customers, to whom they provide their SaaS/customer-facing web apps.
One of our main concerns revolves around security of data, as some of these customer-facing web apps are multi-tenant, so we'd need to ensure that data is always filtered by the client tenant id. Also we have a very customized security model, with data driven roles, permissions that may prevent showing certain types of data (e.g. SSN, Salary, etc) etc.
Does Tableau fits this model, can it meet most/all of these requirements, or is it meant more for internal data?
It should be quite possible by setting up a reverse proxy that would front end your multi tenant web application. There is a document on how to setup Apache as reverse proxy with Tableau with/without SSL.
I am familiar with how to configure Apache as reverse proxy and so here are the details with Apache Web server on how to setup reverse proxy rules.
There may be some documentation for front ending with IIS/Nginx so you should do some googling by yourself.
You need to harden your webserver configuration by limiting access from the external firewall to read only pages and the internal user can access allpages. Since you mentioned that the external users are allowed access to readonly pages, I presume all the requests from external requests will be only GET requests and a few PUT/POST requests when users choose to use filters. So you can block external users from any request except GET. Exceptions should be made for the pages that allow applying filters and grouping.
In your mutitenant application make sure you refer to the tableau URL's by the apache server url that is exposed to the outside world. If any url not configured in apache is used, users will recieve a access denied error. You need to create a role that has readonly access to tableau pages for external users. To address mulitenancy you need to set a cookie or something to identify the tenant and something similar to identify the user. To filter SSN and some more information you can use mod_proxy_html which filters content. You can also use mod_security module of Apache to block SSNs and Credit Card Numbers.
References:
Configuring Apache Server as Proxy with Tableau
Apache mod Proxy documentation
Blocking POST requests
mod_security FAQs
Yes to most of your questions -- with just a little fine print.
First remember Tableau is primarily about visualizing data, so it is great for publishing readonly interactive views of data. If you want allow end users to edit data, you'll have to do that by another means. Fortunately, the Tableau JavaScript API lets you interact closely with Tableau with your custom Javascript code. So if your needs are mostly about visualization, but want want to be able to trigger some custom code to modify data in some of your apps, you should be fine. But Tableau is not designed for creating custom CRUD apps as a rule.
The great thing about Tableau server is that many people can learn to use it and publish their own visualizations -- even if they don't know how to program. That doesn't mean they will win visualization design awards the first time, or that they shouldn't learn something about how databases work if they want have good performance. But it does mean the people that know their data best can learn to design and publish their own visualizations without having to wait three months on a backlog queue so the one IT guy can change the color of a button or add a field. It still would be good to get good system, database and visualization folks to help train, organize data, set governance and security rules, optimize, etc, but business users can learn to be the ones with hands on control over how their information is presented. That's a good thing.
The security question has several moving parts, and usually there are usually good answers from Tableau depending on what you're trying to accomplish. Tableau server does support multi-tenancy using sites. There is fairly flexible permissions and group policy system. It can use SAML for authentication, and has several features providing access to specific to the user/tenant. It works with almost every database, and you can in some cases push your security enforcement to the database server -- SQL server for instance. There is a trusted ticket feature where you can defer some authorization decisions to another server, say a web portal server. Useful when Tableau visualizations are embedded in some other web page.
Most security use cases can be supported out of the box, but there are some complex custom access control situations that are tricky to implement currently in Tableau server. Nothing you've listed sounds out of the normal swim lane, but the only way to know whether your security model is too complex is to dive into the details. Hopefully they will release a custom access control API for users who want to extend it.
At the high level, you sure can use Tableau to build customer-facing dashboards. You can quickly build and deploy those and as others mentioned, you can iFrame them with Javascript APIs, you can customize most of it. But it doesn't provide complete flexibility for user interaction, which you can if you use other technologies. Other options include hand coding framework and then using charting applications.
For simple dashboards, Tableau would be the obvious choice if you have already bought core-licenses. But when looking at what's going on in the industry, Tableau will not be able to fulfill all needs.
If using Tableau
1. Building Charts/Tables/Visualization is a super simple, efficient way.
2. You can expose low grained data to customers, because of Tableau's propitiatory columnar database engine, you can potentially expose millions of records via a dashboard.
3. You can use Tableau's security and access control mechanism.
4. As other user mentioned, you can use trusted ticketing mechanism to integrate easily with other applications (portals etc).
Challenges with Tableau approach.
1. If you have late arriving transactions (in Internet world it's so common to mark a click as fraudulent after few days) with late arriving transactions, you have to have full refresh the extracts, which means if you are showing say 13 months worth of data, you have refresh it all, all the time. Now with bigData, business needs all data all the time, which means you would end up extracting millions of records, throughout the day.
2. Very little flexibility in user interactions, like menus,drop downs etc. you have to work with what's been provided by Tableau.
3. If you have multiple charts on same dashboard page, not so user friendly way to download underlying data.
4. Many other challenges, in laying out visualizations on dashboard page, as there is no easy way to control canvas with pixel control, white spaces etc.
You should be very careful, after analyzing your use case, whether Tableau would be the right product before you invest in it.
Tableau's primary power comes from its desktop tool for data visualization/exploration and not from pre-built dashboards.
Best of luck.
Since Tableau public is also based on Tableau, I assume that you can put your dashboards in public using your own Tableau infrastructure.
Is it possible to make an integration between Alfresco and LDAP to manage groups, users and permissions?
I mean, alfresco groups must be managed with its own set of permissions? Currently I have a LDAP repository to allow authentication, but it is a lot of work to maintain users and groups across multiple systems.
In other words, can i make a full integration between these two environments easily and without modifying the core of alfresco?
Thanks in advance
Short answer is no.
IMHO, externally managed users, groups and authentication are already the maximum to make sense of. Even then, a part of authorities (users / groups) will still be created locally in alfreco when you start using share sites and invite external people. Sure, this could technically be changed, but alfresco writing to LDAP opens a new can of worms. The default LDAP read/sync approach should not cause sigificant extra efforts.
Authorization data, such als roles (which can easily be confused with groups) and permissions and their semantics are highly dependent on application (alfresco). It does not make sense to manage them in an external system that has no clue.