i am working on a project that contains more than one application.
there are finance app and HR app. i think it is not efficient if i loaded all files for finance and HR for a user that will use only one of them.
i need to split them into two separated applications having the same login page and also accessing the tokens from the login services.
any explanation for how could i separate them , how will route work and ng-view work and also accessing of main app data (tokens).
Have you considered using local storage (I think that might work).
I found this library helpful:
ngStorage
As it allows you to interact with localstorage with usual angular binding. That way you can have both apps read the local storage as they are operating out of the same domain.
It is very simple.
Make your HR and finance two html pages.
Server redirect to each html page by account type.
You can access the same tokens in both html pages because tokens are included in session which is stored in browser cookies. cookies are by default shared in the same domain.
Update
I guess you mean to use the same singleton "angular service" in two different instances of "ng-app".
In this case, I don't think it is possible.
My solution means that don't store the tokens inside an "angular service".(I don't think this is normal way because every new tab will create a new "login service", so every new tab requires a login process)
Instead, store tokens in cookies. Use "login service" to get tokens from cookies. In this way different instances of "login service" will get the same tokens
Related
I have the following problem in Angular. If I have two pages A and B each containing a table. Then I make changes to Page A in the table, and then navigate to Page B. Now I expect that when I navigate back to Page A, the changes are still there. I don't want to send the changes to the database until I click a save button. What is the best way to solve this in angular?
If you are only wanting to preserve the data for this one instance, then definitely look to using a Service and writing your data to localstorage for it to persist across page refreshes.
If you are developing a SPA, then I'm not sure why you need it to persist across a page refresh since moving between components does not actually send a new HTTP request. You state should be preserved in your Service.
If you find yourself needing to manage state across your entire application and want to do it reactively, I recommend checking out NGRX.
https://ngrx.io/
Another alternative that maybe has a little less boilerplate is NGXS, which does the same thing as NGRX.
https://www.ngxs.io/
I don't recommend to use localStorage for your task if you develop SPA application, because localStorage/sessionStorage is limited and it is designed for another purposes - like authentication etc. But of course if you need to preserve your data - like cookie/JWT token etc. even after refreshing the page you can use localStorage.
I recommend to use Angular services for this: please see examples at docs Services/DI docs. Once you registered service as a singleton Singleton services, you can inject it via built-in DI(Dependency Injection) in component which renders your table at page A. But of course, you are not limited in injection only in component which located at page A, you can inject it even in page B etc.
From the server I get a list of places that the session user has access to.
Now I want to store these roles where I can show or not display the route or buttons for the user. Where is the best place to store this data in Angular?
Short answer
Inside of a service.
Why?
You mention that you receive a list of places from the server: the client can use for example Chrome's Developer Tools to inspect the network traffic and just read the list of places there.
You should secure the access to your routes and content server side, and don't worry about the client-side "security". The user has access to the full client-side source code. If the client-side environment can decrypt or access something, then eventually so can the client.
There's many kind of storage available on the client side: There's the LocalStorage API for persistent storage, or you can make an Angular service that transiently stores the retrieved role information. But just keep in mind that your user can read everything that you write in your Angular application, so trying to keep buttons or routes hidden won't work on power users going through your code.
I built a web application that i have running on multiple raspberry pis, I wanted to add storage that is shared by all the web app instances. Basically what I want to achieve is for each instance I open in my browser it saves the device name and URL to my browser (Local storage is what I went with but it's not shared) the web app would then open the storage read all previously accessed pis for easy switching.
I tried to do this using local storage but didn't work as apparently it's per instance and not shared. anyone can suggest a proper way to achieve this ?
Local storage is exactly as it sounds - local to the browser (and machine). It's used to store data between multiple sessions with the same app/website on the same machine/browser. If you want to share some information between multiple instances of the app running on different machines or in multiple different browsers you need to store it on the server.
How to store it on the server is then a separate question alltogether (with a wide range of options, e.g. writing to a file or a database). In any case, the implementation will need to be separate from the client app.
Local storage keys are shared on a single device if requests originate on the same domain.
Consider the following example of how keys could be shared:
You have the domain http://example.com
You have two apps hosted at http://example.com/app1/index.html and http://example.com/app2/index.html
You have a local storage key for last visited where the value is a date string
If you go to app1, it sets the key.
If you go to app2, it will be able to retrieve the key set in app1.
Are you having trouble with getting localstorage to be shared across instances in this manner?
If the apps are on different domains, or you're trying to share information between devices, you'll have to use a server to share the data.
Local storage is local to the current domain. There is no storage that can freely be shared between all web pages built into a browser.
If you have multiple web applications / application instances, they need to know about each other to communicate (via cross-frame messaging) and exchange their URLs to have each store them locally and display them. There are a few approaches how to do that:
have the user explicitly add other domains he knows about so that you can contact them
have the servers announce their presence on the local network (or use a configuration file on each server) so that they know about each other before serving the web site
have a central ("storage") website at a known domain that every application website will contact
I have an existing website which is built using express and node.js , I have to incorporate nodebb forum in that website which is again a different node application, I am using facebook login for both of them but I have to login into them seperately one by one(using same facebook app for both). What I want to do is,
1.Login via fb or any sso in the main site and the user should be logged in the forum via the same automatically.
2.How can I integrate nodebb in my website so that the look and feel doesn't change, it looks like I am on a completely different website, just need some tips to integrate nodebb in my existing website.
How can I achieve these two?
(Hey there #Vipul, NodeBB dev here) When you establish the express session your app, what are you setting the cookie's domain to?
;domain=domain (e.g., 'example.com', '.example.com' (includes all subdomains), 'subdomain.example.com') If not specified, defaults to the host portion of the current document location.
-- MDN
You'll probably want to set it to .your-domain.com, and likewise for NodeBB (do it in the "Settings/Advanced" section):
Then also make sure the key in your app is set to express.sid, which is the value we use, and that the secrets match.
I'm planning to refactor a legacy Rails 2 app by splitting the logic into a RESTful API, and the view into a separate Javascript client. The API itself will be protected by oAuth2. This is basically the second option explained on this question:
Separate REST JSON API server and client?
There's a lot of questions out there concerning the security of using oAuth with a JS app, the main concern seems to be that storing the access token on the client is a bad idea since it acts as a password and someone that has physical access to the computer can hijack the user's identity. A possible solution I've read is to expire the access token every 1h or so and use the refresh token stored on Yahoo's YQL to request a new token when necessary. This doesn't looks to me like a good solution since at the end you'll need again a token to access the YQL service.
But at the end, aren't we facing the same problem as when using persistent sessions? I mean, AFAIK, the common method to keep the session alive across browser opening/closing (when you tick "remember me") is to generate a token associated to a user and store it both on the DB and on a long-living cookie. So again, anyone with access to this cookie has the "key" to your session. AFAIK this is the method all the "big guys" use.
I am right? And if I am, aren't we worrying too much about something that we cannot control at all? Of course I'm talking about those applications where an intrusion is not too harmful for the user like social networks, blogs, forums, etc.