What is Maximum capacity of vu e2 store - vue.js

In my application multiple user can impersonated for a specific role. User can change impersonate app any time. As fetching data takes time. I want to keep data in store for user for which already data is fetched. I want to understand about capacity of VUEX store. What is recommendation for it. If you have any article around it, please share. I am using vue 2

Related

How can I set up a similar structure to local storage in vuejs3

I am working on a project with vuejs3. I need to save some data somewhere globally and call another page. I was using local storage for this, but this doesn't feel right and it gets harder to manage as the project grows.
at user login
lookie.set("userType", "student")
at another component
lookie.get("userType")
For example, there are two user types as student and teacher in the project, I keep their user type in the local storage at the user login, and I do not display some components if the user type in the local storage is student.
I used the state structure, but it didn't work for me because it reverts to its default value when the page is refreshed. What kind of structure do you think I should set up?

MVC - Store secure information

I just come a cross with this question during my MVC studies.
Is it possible that b is the correct answer?
You are designing a distributed application. The application must store secure information that is
specific to an individual user. The data must be automatically purged when the user logs off. You
need to save transient information in a secure data store. Which data store should you use?
A. Session state
B. Database storage
C. Profile properties
D. Application state
Thanks,
If "The data must be automatically purged when the user logs off", then there is literally no need for B or C. D (application state) is single across users, so your best bet is A.
From MSDN
...application state is a useful place to store small amounts of often-used data that does not change from one user to another. For information on saving data on a per-user basis see ASP.NET Session State Overview and ASP.NET Profile Properties Overview. [Ref]
This indicates A and C are possibilities, however -
[Profile properties] is similar to session state, except that the profile data is not lost when a user's session expires. [Ref]
which does not satisfy, "data must be automatically purged when the user logs off.", leaving A as the appropriate answer.
My thoughts on this question: Session in asp.net can be configured to store info in db, and by default it stores info in-proc, that's not suitable for distributed application.
So, session option alone does not fit. But db option can be used with session: this will satisfy condition of purging info after user logoff from one side, and store info in secure store (db) from the other.
Upd. If i could choose multiple options (each as a part of solution) i would choose session + state server or database. But since i can choose only one answer, i would prefer session.
It is possible for B to be a valid answer, but A is a better option.

What defines a client/user pair for Google API refresh tokens?

According to Google, there is a limit (currently 25) of how many refresh tokens can be given per client/user pair.
Just to clarify, this is referring to each user, right? Meaning that if I have a million users (!) each user could have 25 refresh tokens active? Or does this mean that I only 25 of the one million users are able to store refresh tokens on my server?
I am referring to the bottom of this page:
https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtAuthorization#helpme
Ok trying to figure out how to explain this:
When a user says yes they will allow your application to access there data you get a refresh token. You should save this refresh token some place so that you can use it next time. Then you will never have to ask the user to authenticate you again.
But if for some reason you ask the user again can I access your data you will get another refresh token. The first refresh token is still good you can still use that to access there data. You can do this up to 25 times before the first one gets deleted.
Here is a real life example of when this can be a problem:
I have an SSIS connection manager that asks the user if i can access there Google Analytics data. (works with a datareader but i digress). I have run into a problem where the user has to many packages authenticated. Basically they installed my application to many times in testing and the first one stopped working.
In the end i just recommended that they have a dedicated account for using my Task that way they would reduce the change of hitting the 25 authentications.

Magento ->Tell if user logged in using straight SQL

How can I tell if a user is logged in using straight SQL based on their email address?
We have a system that is highly coupled with ExpressionEngine and cannot use the Magento API in many of the EE templates.
Edit to show current login code:
Mage::getSingleton('core/session', array('name'=>'frontend'));
$session = Mage::getSingleton('customer/session');
$session->login($ParticipantInfo['PreferedEmailAddress'],'default_password');
$session->setCustomerAsLoggedIn($session->getCustomer());
TL;DR: As far as i know, even if session data is stored in the db, there is no definite way of telling only via plain SQL.
Question would also be: Which user? Customer, admin or api user? Assuming you store session data within the file system, I could think of some options:
API
For API-Users, have a look at the api_session table, you can do a join with the api_user table, which stores the email address. However, there is no way, the information in these two tables will suffice, as only session id and logdate are saved for a specific user id and you have no way of telling if a session is still active.
Querying for this data those would probably be something along the lines of:
SELECT *
FROM api_user
INNER JOIN api_session ON api_user.user_id = api_session.user_id
WHERE api_user.email = "<known_email>"
Admin & Customer
Admin users are stored within admin_user, however, like for api_user, no information is stored along for session management.
Customers are stored within the customer_* tables. You can look them up in the log_visitortable:
SELECT *
FROM log_visitor_online
INNER JOIN customer_entity ON customer_entity.entity_id = log_visitor_online.customer_id
WHERE c.email = "<known_email>"
Again, no information can be retrieved, if the session is still valid. EDIT: Tim showed how to do it correctly in his answer.
The bad news, in general
No information is stored directly, if a user is logged in currently, only, when the creation date of the session. With out-of-the box functionality you should not be able to tell accurately via SQL if a user is currently logged in or not - this would be insensible at best, as magento checks the user's session's validity against the stored session data in the db/filesystem, so without the user's session data, you can determine nothing with 100% accuracy.
The good news if you can write a module
With a little bit of work you can hook into the session management of Magento. There's a cheat sheet for events the core ships with. You can also create you own custom events, which you may listen to and execute code upon.
The idea here would be to write a module which could store extra information on the customer (admin or api user vice versa) or within an extra module table. You can hook into the login process and set a timestamp for the api_user/customer/admin has logged in and refresh that timestamp upon a request. If a user's timestamp hasn't been refreshed for, let's say, X Seconds, you assume the user is logged in any more. You delete the user's timestamp upon the logout event.
However, this is also not 100% accurate and it heavily depends on what a user does in you system.
Anyway, I hope I could provide some insight.
lg,
flo

How to save user data in an iPhone login type app

Im developing an iPhone app with user logging design and i am trying to understand how to save user data and app state for each user in the same iPhone.
For example suppose my app flow is as follow:
1. user log in.
2. app gets the user friends list from core date and present it.
3. in the background the app fetch the user friend list from a server and update core data.
Now suppose there are two users that simultaneity uses the app with the same iPhone
how can i know witch data to load from core data to each user? haw can i know witch app state to return to?
First of all, it seems important to pose the question of why you are trying to do this in the first place. As I'm sure you have noticed, Apple designed the iPhone to be a single user device. This is why you don't see their apps (and generally apps from 3rd parties as well) allowing multiple users.
That said, if you are absolutely sure you want to do this, then you clearly need to give the user some ability to change user accounts. You're never going to know when one person is using the phone over another, so you have to provide the ability to switch users similarly to how fast user switching works in OS X.
Anyway, you probably need to start by creating an additional Core Data entity called "User". That entity should contain information about each user (name, nickname, photo, etc). Then you need to create a relationship from the "User" entity to whatever entities you are using to store your friends list.
You'll need to decide what the behavior of the app will be. Will the current user automatically be logged out when the app quits? Hard to say as you don't know who is going to use the app next.
I would create a core data entity for users and link the entries in it with the friend list entries. Therefore every user should have a unique identifier. Also in your friendlist entity there should be a key like "userId" to hold the reference to the user.