I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
Related
I would like to develop a new web-app in node.js (using express). I am relatively new to node.js world, so I assume there are frameworks that I am not familiar with.
Is there any framework (like Spring for Java) that manages authentication (and save the trouble from the developer)? Or each developer has to write this code over and over again?
Login/Logout is not all. There are other flows:
registration (create account),
forgot-password (and then set new password),
locking/unlocking an account,
change password
and I think I have covered all flows.
I know that each application has its own UI, forms, maybe with its logo, but the flow itself is similar for most applications.
In addition, I know that it is not that hard to implement, but it could be great to have some kind of tool / framework / infrastructure which implements the flows.
Is there such a tool/framework which helps applications' developers and implements these flows?
I've searched this issue but could not find anything.
Thanks!
Long ago I have developed authentication-flows for Java over Spring, and recently I wrote authentication-flows-js.
It is a module that answers most flows - authentication, registration, forgot-password, change password etc., and it is secured enough so applications can use it without the fear that it will be easily hacked.
It is for node.js applications (written in TypeScript) that use express. It is an open source (in GitHub). A release version is on npm, so you can use it as a dependency in your package.json.
In its README (and of course in the npm page) there are detailed explanations for everything and if something is missing - please let me know. An article will be published soon (I will add a link as a comment).
You can find here an example for a hosting application.
NOTE: I have heard comments like "It's not so difficult to implement". True.
But you have to make sure you take care of all cases. For example,
what happens if a user tries to create account that is already exists?
what happens if a user tries to create account that is already exists
but inactive? what about the policy of the password? (too long/too
short/how many capital etc.) what about sending the email with the
activation link to the user? how you create this link? should you
encrypt it? what about the controller that will receive the click on
the link and activate the account? and more...
I am going to building a very large SPA based ERP SaaS with react.js at frontend which has a really complicated role and permission-based system. I have done some analysis of my application so I realized that I must make a proper architecture of my application so that I shouldn't regret and worry about my application and it's scalability in the future. Mainly I was worried about role and base management. Where I need to switch between different components at first load.
Backend I am working with on this project: Php and node.js
My Exact Problem:
I have about 500+ permissions with 100+ roles in my system. Some roles get only 1 to 10 permissions. This results in switching and showing the only component of that permission in the client browser at the frontend. My main problem is Why should I load unwanted components in the client browser of which users don't have permission to access ?
Problem Example: Admin has given only 3 permissions to Mr.John in their system . Where system contains total of 100 permissions. Each permission results in switching and viewing 100 parent components. If Mr.John has only 3 permissions which should switch only 3 parent components so why other components are sent to the client browser?
What did I want to do?
After authentication, I want to verify the permission and role of that user at the backend and send only the required resources to the client. So that My application size depends upon the role and permission that a particular user has.
To solve this problem what I thought (Not Sure) :
Before this project I have a similar project at PHP without using any complicated frontend library. It was really easy during the development phase. I have worked with React and Vue. But I have never used Server-side-rendering. I thought the concept of SSR could help me so I went to tons of sources and learned about SSR. (Still, I am not sure that the concept of SSR can help me. )
Please Help me to make the proper decision?
What I understand about your problem is How can browser load exact files based on role and permission instead of all files.
Code-splitting is what you want exactly. This is not just React but for all front-end framework(or library) by using webpack
Read official articles
https://reactjs.org/docs/code-splitting.html
https://webpack.js.org/guides/code-splitting/
Maybe entry point of a bundle(webpack) must be simple. After getting a role and permission, the browser has to load components you want. Also, maybe react-router helps you. Or if you consider server-sider-rendering, next.js is for you
In my company there are 3 independent projects written in angular. The customer has asked the company for the following:
create a project which will enable the user to connect to each one of the independent projects.My question is a general question - is iframe the correct technology for this usecase - and what do I need to know when I use iframes for that use case.
This is what we do, the iframe communicates with the apps and gives the token (it is called on init of each app) then you can provide some type of menu (or app picker) inside the header component where the use can choose any app. Keep in mind that the cookies/ls are saved on browser so presumably if the user hasnt logged out and your authentication is setup correctly they should be able to switch between apps just by switching URL's
I'm developing an extension and I'm a bit stuck about the communication between the web-app, the content-script of the extension, and the communication between the content-script and the background-script. It seems to be that HTML5 Messaging API is to be used, but how to do that in a precise context is not only hard to understand and implement, but also confusing due to differences of approach in Browsers (which seemingly support the same API).
For example, Firefox doesn't recognise the externally_connectable in manifest.json, which is where one assigns permissions for the hosts where requests originate from. So how does Firefox expect you the developer to assign the permissions? I assume it expects you do that within the content-script?
Particularly, I'm confused about what is the best way to exchange data between the app and the content/background script. Is the best way postMessage / addListener methods and do they work in all contexts; or as someone mentioned: window.dispatchEvent should be preferred?
All guides relevant to the point above are appreciated.
Messages coming from outside the extension is not something I have experience with (and I'm not sure that's what you mean).
You should make sure you thoroughly understand the chrome extensions overview which is definitely required reading.
re Window.dispatch and using other APIs, my suggestion is stick to the chrome.xxx APIs unless there's something they can't do.
There are 3 scopes potentially in your extension that can only communicate by messaging but the messaging is simple to implement and actually can lead to good designs.
Content scripts are the key to interacting with the page itself but their scope isn't the same as the page, the js is isolated but they can access the DOM of course.
Content scripts can be loaded when every page loads or just some pages by including them in the manifest. Or powerfully, they can be injected by the background page or the popup - so if you're intention is to control from the popup, you can use programmatic injection - a useful pattern is that the popup (or background) can launch a url in a tab, inject jquery (any version because it's isolated), then inject the content script, the content script can then use $(document).ready() to wait for the page to be loaded (don't have to use jQuery but the fact that you can without caring whether the page has jQuery or not, or what version it might have) is useful.
If you already knew this much, you might not be as confused as you think :)
So, apparently I need to provide a Privacy Policy URL for my Instagram application.
The only reason I'm using this application, is for a website I built for a client of mine. The client wanted an automatic integration for her Instagram, so I went through the whole Instagram API hassle.
Now, the website is ready for production, so I wanted to get my app out of sandbox mode, but it looks like I need this Privacy Policy URL.
What's the best way to go about this?
Put a Privacy Policy page up on their website (really any website you can link to) and use that link. It can be a static HTML page, as long as you can link to it.
Instagram won't let you take an application like this out of Sandbox, btw. Your use case is not an approved use case. From Instagram's Developer Documentation under Invalid Use Cases:
One-off Projects. If you are an agency building websites or other integrations, note that we don't grant permissions to clients created for one-off projects. If you are interested in building a product, platform, or widget that will be used as a service across multiple projects, then you may submit a single client_id that you can use across multiple projects.
You can (probably) still achieve the outcome you're looking for but you will need to go back to the drawing board and rethink your application's use case before getting out of the Sandbox. I know some developers who really just don't understand (or care to understand) the policies and never make it out of Sandbox. It's a shame because they can read the technical portions of the documentation so easily but just can't/don't read/understand the more critical parts (like the Invalid Use Cases section).