Our application has a multi-tenant architecture where we have multiple different websites deployed using a single codebase. Is there a way to edit the application name (ie. show Sign in to <Website 1> with Google instead of Sign in to <App name> with Google) without needing to create a separate project in Google Console for each website?
If editing the app name is impossible, is there a way to just show Sign in with Google instead?
I don't think Google allows you to do that, basically due to some legal/UX concerns. Take below UX as an example.
Users go to website1, and see prompt for "App Name 1". Then grant it.
Users go to website2, and see prompt for "App Name 2". And it'd be a big surprise, to some of them, that the permission has arleady been granted. Users may think 1)Google granted it without user's consent, or 2) someone had stolen his credentials and granted it, etc.
In summary, you need to make a decision first:
if you think end users should treat your different origins as different apps, you should create different projects for them(, so that their UX are isolated from each others).
if you think users should treat your different origins as a single app, then using same app name is not an issue at all.
Related
Is it possible to get an app script code to stop users from opening another window/ tab while filing up a form/quiz? What are the other possible solutions?
I don't think this is possible via Apps Script code. However, there are different ways you can achieve this depending on devices users log in to. For instance, there is this option Use locked mode for quizzes for ChromeOS devices. Furthermore, if you have Google Workspace users, you can block by URLs using a Local policy or remotely from the Admin console. These last 2 options, block users from navigating to other web URLs by using the wildcard "*" except the URLs you specify in the "Exceptions".
If you have other browsers installed in users'devices, then you can create a temporal Context-Aware access rule as specified in these steps. With these rule and the correct Google Workspace edition, you can block access from any other browser except Chrome.
I'm currently developing a Chrome extension to use with LinkedIn Sales, and I'm having issues while testing the front end.
Due to some style changes, I had to refresh the page multiple times and now my account is temporarily banned because they confused me with an automated tool.
Does anyone know a workaround for this? Or, alternatively, can I create some type of developer account to use?
TIA!
Due to some style changes, I had to refresh the page multiple times
This is really a suspicious action.
So isn't your "Chrome extension" also an automated tool?
Either get some API access (you find available APIs here https://developer.linkedin.com/product-catalog)
or if you just do some visual brush-up for users, you could try to make an offline copy of the page once (with a tool like HTTrack) and then use that copy for development.
For the Sales API it says
It's required that all integrations are built by approved partners for the SNAP program. To become a partner, visit this page.
I am trying to make multiple pages with the name of users which will then be shared with each them. However, once I tested it by adding one of them, they managed to get to the page, but no results are shown when clicking at the button for pulling the data from the Drive Sheet. The circle is doing a single circle and that's it - no data, only the headers are shown.
Is it required for the users to have the file shared with them in Drive in order to pull it on Google App Maker or is there any security setting that I have to adjust?
Settings in the publish menu:
User roles in Security in the PAGE and DATA:
There are no errors in the Developer or Preview tab.
If you go down with Spreadsheet approach, then you'll face with implementing CRUD operations almost from scratch, what is opposite from the App Maker mission.
only the Admins want to see everything
Out of the box deployment Admins can see all data
employees access only for the accounts assigned to them
You can achieve such security configuration by adding Owner field to your model (Record Permissions).
Take a look at App Maker Templates, there are lots permission configuration samples.
So I may have a bit of a strange situation here, and I need some guidance.
The company I work for has a number of small sites, with each site selling a different custom program. The sites are badly in need of an entire rewrite from top to bottom, and my boss has agreed that a login and online purchase/registration is required. This means user accounts, the ability to download a trial from within the user account, the ability to register that trial also from within the user account and the ability to view a list of previous purchases/registrations and product keys.
The thing is, I want a sign-on from one site to be usable on another. Plus, all of this will need to be administered (on our end) from one admin interface. So my thought is that this will all have to be driven by a single database.
Just to be clear: the front-end for each site needs to be different - sometimes only subtly, but in some cases by quite a bit (marketing differences). The backend (both Admin as well as for the Client interface), is identical in structure regardless of the site URL, but the Client interface needs to show different content (programs to download, lists of computers where the program has been registered on, etc.) depending on what URL is being used.
My problem is that I am not entirely sure how to do this from a code-first perspective. The sites are small, quite easy to build on their own, but I want them all within the same Solution so that a change to the model will be reflected across all of them (I will be able to see where things go sideways if the model gets altered - Intellisense is my friend!).
I have looked into Areas, but Areas seem to be a way of partitioning off gross differences within a site (things like resource files - JavaScript, CSS, etc. - remain in the root, whereas in my case each site will need different resource files). I need each section to be its own unique site, with its own unique URL. When this gets pushed to the server, I need each site to be “independent” in that they can sit in entirely different accounts on the same Windows Plesk server (Plesk was not my choice, but the company has clients that need a control panel interface to their own accounts). The only strong commonality between any of them is the database that they will make use of -- in fact, all of them will be making use of the same tables, with very few differences between the sites.
My other problem is that I do not know how to properly implement having multiple projects within a single solution, and all projects making use of the same model that is implemented/constructed only once. I have not yet made the jump to Repository Patterns, so I am completely in the dark with respect to that functionality.
If anyone has a suggestion, I would love to hear about it.
Essentially, you just need to create a class library where you will put your entities and context. If you're using Identity, you'll also put all the Identity-related entity classes here. You'll enable migrations on this class library. The other projects in your solution, then, will have a reference to this class library. You'll need to add the connection string to the individual projects' Web.config files, but other than that, everything will just work.
This is enough to ensure that all the projects are working from a common database and user store. However, in order to actually share authentication, such that signing into one, signs you into all them, you'll have to take one of two paths, depending on how they will be deployed.
If all of the sites will be on the same domain (different subdomains are fine). Then all you need to do is generate a machine key and ensure that each site uses the same machine key in its Web.config. The auth cookie will be added on the wildcard domain, and any subdomain of that domain will be able to see it. Sharing the machine key is to ensure that they can each decrypt it what any one them sets as the auth cookie.
If not all the sites will be on the same domain, then you're in for some pain. You'll have to set up a SSO system, which is non-trivial and far beyond the scope of Stack Overflow to help you with. There's entire companies devoted just to building SSO systems for organizations.
I am currently trying to figure out how to best go about implementing an administration side for my application.
I have a user site, where users can log in, customize their profile, submit information etc.
I would like administration users to be able to log in and be able to choose from a list of users. From there, the administrator can submit information for the user just like the user can.
Website Start Page > RogerRabbit > Submit Information
Website Start Page > BillyBob > Customize Profile
So my question is:
How should my pages be laid out?
How should the Web.sitemap file look? Is there a nice way of creating a sitemap (maybe in memory?)
Would this method have to use session variables?
Any suggestions, or tips would be great.
I can't answer your sitemap question but I have implemented a solution like this on one of our systems where I can see exactly what the end user is seeing by impersonating them. I did this mainly for troubleshooting purposes so that when they report a problem to me (such as something missing from their view), I can go in as them and see exactly what they are talking about.
The way I did this, which is admittedly a little crude, was to have an impersonation table in my database which contains the logon name of the user who is doing the impersonating and the logon of the user they wish to impersonate.
I added some override code so that when the user first goes to the page (it uses Windows authentication), it will check to see if that user has an impersonation set in the table and then place this user id in an object in the session state. If there was no impersonation, it would place the actual user id in this same object.
To prevent me from doing things to the user's data as them, there are two properties in this object, one for logon_name, which is what is used by the system for content-customization, and another called NameForLog, which is used when logging any actions. All actions I make will be logged as me.
All areas on the site that display user-customized content look at this session object, so they will always use the impersonated ID and therefore always show me what the user is seeing. Beyond the first page and the logging code, it doesn't even know that it is me it is dealing with.
It isn't the cleanest solution, but it has worked well for me.
I dunno mike... that's a broad set of questions there. Kinda like asking "how to I build a web site in asp.net".
It sounds very much like you need to invest in an introductory "how-to asp.net book" that covers these topic areas. The good news is that just about every beginner to intermediate asp.net book ever written probably hits most of these topic areas.
would like administration users to be able to log in and be able to choose from a list of users. From there, the administrator can submit information for the user just like the user can.
This is a kind of impersonation... and is a lot harder than it sounds. But how you do this depends on how your application authenticates users, authorizes users, and manages roles... which is a whole sub-specialty within asp.net (with it's own dedicated books actually).
1) How should my pages be laid out?
Carefully?
2) How should the Web.sitemap file look? Is there a nice way of creating a sitemap (maybe in memory?)
This is covered on MSDN quite thouroughly. Yes, you can create your sitemaps in memory. I've created sitemaps from data stored in a SQL DB a few times in the past, but I'd have no idea where to even start to explain it. You have to understand the base classes and interfaces used by sitemaps and then make a custom sitemap provider adapted to working with your data and rules for the site's structure.
3) Would this method have to use session variables?
Probably. Most sites with an awareness of "logged in user" need sessions. Not universally true, but nearly so.