I have an Angular 4 app that uses Firebase UI (web) with Google auth. For our company staff users, I need to ask for more permission scopes than non-staff users. I don't necessarily need those extra scopes right away, though.
I'm thinking that the login screen will have a "staff login" checkbox that toggles the config. However, the new firebaseui.auth.AuthUI(firebase.auth()) call has already been made.
Is it bad if I call ui.start() a second time with a different config?
Or: is there something I should make sure I do to cleanly dispose of
the prior AuthUI before creating a new one?
Or: (ideally) is there a way to simply force a prompt later for additional scopes, only when needed?
You can re-render the widget with:
ui.reset();
ui.start('#firebaseui-container', myNewConfig);
Related
i have an old asp.net web-form based application, which i want to convert to Vuejs based front-end and Asp.Net Core base api as back-end.
The current application has a login page, where the user inputs his credentials, once the credentials got verified, user is taken to application home page, which has side menu bar.
The side menu bar is loaded based on the current users role/privilege. Say for example, a user with role of admin may have 10 menu items, while a normal user may have only 5 menu items.
I'm very new VUE, so pls guide me, how to set up the vue application and routing for above scenario.
Thanks in advance.
There are many ways to go about this, your goal is to load data about your user into your application.
One way to solve this is to create an API function that returns information about the currently logged on user.
The authentication of the request can be done through cookies, jwt header or something else.
The api call to get the authenticated user data will also help you figure out if the user is already logged on when the app starts up.
Putting aside how you make the network request, lets say you now have the data in your application.
There are a few choices on how to store it, this is an architecture choice as the results of this will likely have effect on many other parts of your application.
The common solution to storing application-wide (global) state is to use Vuex.
This will also play well together with vue-router.
Lets say that in Vuex you will make a field roles that will hold an array of strings, indicating the roles the user has.
In a vue component you can reach the vuex store from the $store property (this.$store in the code, $store in templates).
The state of the store is then reachable via $store.state, and your roles array would exist over at $store.state.roles.
To set the roles you will have to setup mutations that will let you save the roles, and the api call would be part of an action. You can read more about that on the vuex documentation on how to update the state.
I am considering enabling multiple tenancy on an existing app that uses Firebase Authentication, having read this https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication
What I'm not clear on and therefore worried about, is what happens to my existing app users once I add a new tenant? Will they be unable to login unless I migrate them to some "default" tenant?
I haven't found any assurance or explanation in the docs, so maybe its ok, but I don't want to click that button unless I am sure. And is there any way to back out of enabling multi tenancy in the event of a disaster?
So in the absence of any reassurance, I just went ahead and clicked the button. Nothing bad happened to my existing users. They were migrated from Firebase authentication to GCP Identify Platform, under the context of the project, which runs along side tenants it seems.
Then I was free to make another tenant, which formed an entirely separate space to configure providers and house user identity.
When store owner installs my app I save access tokens into database for later use. Having access tokens from store is huge security responsibility because anybody with these tokens can modify stores from any domain/address, there is no ip or domain lock.
What method could I use to make this more secure? I was thinking to save tokens offline and then upload it only when needed (in case I need to make some global updates for all stores), then delete it again. In case when merchant access app configuration within admin, I would just save it into session. Is there any better method?
Good question.
I save them in a database as well but I encode them with a separate key from the Shopify App password. That way even if someone have access to the database because of some backdoor entrance he won't be able to use them. That said if someone have access to the code he will be able to figure out how to decrypt it since he will have access to the key.
That said I make sure that each and every request is authenticated before I show any response from the server. Since I'm using NodeJS as the back-end I make sure that there are no global variables that can be accessed or modified from different stores. Everything is neatly scoped in separated functions so that the session is scoped for the current store and no other ones will be able to dirty the other store session.
In addition I make sure that there is a webhook that fires when the client uninstall his app in order to clear my database from any information regrading his store.
I know some people are using sessions for this ( online method ) but they pose other problems that I didn't like so I stuck with a database ( offline ) since that is the quicker way to access the App instead of multiply redirects in order to save the session.
As for proposals I can give you a few tips that I learn on my way while building a few basic Apps. ( I'm not an expert on the subject by any means )
don't rely on any cookies when it comes to sensible information
authenticate every request that comes from the front-end
don't trust the user and validate any input that comes from the front-end
don't over-complicate your setup, while it's good to have high security it's bad if it makes your app slow for the user and you lose customers
look to other ready to use popular solutions that can guide you to the correct path
don't get greedy with the App scopes, only request the scopes that you need for you app
remember to clean up after yourself when it's possible but don't over do it ( too many Apps modify the code of customers and break it only to prevent any way to clean it afterwards ) Example use the ScriptTag API instead of a liquid snippet using the Asset API. If you have to use the Asset API add only the parts that you know that won't break a site. Creating a variable is ok if you are using var if the site supports IE11 creating a variable using const or let is not OK or using vanilla JS is OK but using jQuery without knowing for sure that the site has it installed globally is not OK.
More insights on the matter can be seen here:
https://help.shopify.com/en/api/getting-started/authentication/oauth/api-access-modes
https://community.shopify.com/c/Shopify-APIs-SDKs/Best-way-to-store-shops-that-have-installed-my-app-and-their/m-p/402972
Being in a view and you know the area-name, controller-name and action-name of a destination to which you want the user to provide a link to, how can I figure out if the area/controller/action is authorized for the authenticated user.
Imaginary Use-case:
I have a table with a list of books (the result of bookscontroller.index). To the far right are some icons to edit or delete a specific book. The edit link refers to bookscontroller.edit and the delete link to bookscontroller.delete.
On the actions there are custom authorizationattributes and this works perfect. If a user want to access books/edit/1 and the user is not allowed to edit books, the user gets redirected to the logon page.
It is a bit stupid to have that edit-icon there if the user is not allowed to edit books. So at view level I would like to be able to figure out if the user is allowed to use the edit action of the bookscontroller. If he is, show the icon if not, do not show the action.
Goal: use that knowledge to create a custom tag-helper.
The go-to method is reactive, i.e. you check if a user can do action when the user tries to do. Since you do not want to go that way, here is how. (yet, this is anti-pattern)
Have the authentication token of the user send back to backend. The backend should have an API end point for each button on the page user can click. With the authentication token, the back-end resolve whether to dim or enable the buttons.
Now, what the backend does to resolve this is not very efficient. The backend needs to literally attempt certain actions and aborts the transaction. For create and retrieve, it is trivial (you can pre-resolve them) but for edit and delete, this requires a lot of resources.
The standard way of controlling such actions on UI is to use role based authorization.
For the buttons or other such UI elements, setup role tags, e.g. "admin:edit", "viewer:readonly" etc.
When you are authenticating a user, send the applicable roles from the backend server, store them in a way that is globally accessible to your UI and use them for filtering UI elements across your application.
I'm using Django-allauth for social and simple login. I want that when a user who hasn't signed up or isn't logged in makes a shortlist of items, the shortlist is still present when the user signs up or logs in. So I'm using Django-lazysignup.
Right now, a new lazy_user is created everytime I'm not logged in with Facebook, or it gives me a "column user_id not unique" error. The shortlist is also not converted.
How do we integrate the two? Or how do we do this without using lazysignup?
Any help on this would be great, thanks!
Have a look here:
https://github.com/pennersr/django-allauth/blob/327f5b60f31e9b3db18d461266084a44f04888dc/allauth/account/adapter.py#L117
and here:
https://github.com/pennersr/django-allauth/blob/327f5b60f31e9b3db18d461266084a44f04888dc/allauth/socialaccount/adapter.py#L40
Here, a new User instance is created for local and social users respectively. These adapter methods can be overriden, and instead of spawning a new instance they could be changed to return an existing lazy user instance.
With django-allauth out of the box you will probably run into the problem that you don't have access to the request instance here, but I am willing to adapt allauth to match your use case...
You could use a custom user model (Django 1.5) tweaked in a way, so that it uses the session key as identifier for example.
Later on signup.. just fill in the username and/or email etc.
This could make sense if you want to save the lazy users interactions even if they do not sign up (e.g. for statistical usage). I have not tested this.. but it might work. :)