I use scopes:
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/userinfo.email
but result data of:
https://www.googleapis.com/oauth2/v1/userinfo
https://www.googleapis.com/oauth2/v3/tokeninfo
not contains info about exist two-factor auth on google account.
Can I get boolean or another value about it?
Sorry we don't expose If a user has 2 factor auth or not) through API. We have been thinking about this for a while.
We have been doing a lot of things to improve the security for all users (including the ones who have not enabled 2nd factor). This is based on the risk signals and we ask for second factor if the user has a phone # on their account even without a user enabling "strict" 2nd factor. This allows us to protect all users. The difference being in one case 2nd factor is required in all sign-in vs required when we think there is risk.
The problem is that if we do expose whether a user has enabled strict 2nd factor, a lot of 3rd parties will "force" users to become a "strict" 2 factor users without understanding what that means. So for now we don't have a timeline.
Related
I want to provide users the ability to access a whole bunch of route groups / routes / intents from an "is there anything else?" kind of prompt. But, I want to limit access to some of them based the value of an event handler or parameter (eg client-membership-class=xyz) because some intents are irrelevant to some membership classes, thus I want to prevent them from accessing them.
It isn't practical to limit access by making a flow or page per client-membership-class because there are more "client-membership-classes" than there are routes / intents I need to limit access to.
On that basis you may think I've got the cart before the horse but I don't for 2 reasons:
the intent fulfilment is client-membership-class specific, populated via webhook.
the [routes / intents I need to limit access to] represent a very small portion of the overall agent, thus it would be much more work to make (and maintain) one agent per client-membership-class.
Attempted solutions:
Conditions on routes only prevent fulfilment and can't prevent invocation.
I'm struggling to find almost anything on using intent "labels". I suspect a label can not be used in a scenario to disable an intent (?).
I'm open to a complex solution if it can be achieved via webhook during a session.
Any ideas would be much appreciated !
To set up an account on the NEAR blockchain, it requires you to send some number of tokens to fund that account. For example, when using the NEAR Wallet to set up a new account, you have to fund it with 3N first. Why is this?
You can create a NEAR "implicit" account with 0 NEAR. Near implicit accounts are the same as in Ethereum or Bitcoin. You create the a keypair locally and the public key becomes your account id (a hex string, like in Ethereum or Bitcoin)
See here: https://nomicon.io/DataStructures/Account.html
and here: https://docs.near.org/docs/roles/integrator/implicit-accounts
You only need 3 NEAR if you want to create a "named" account, that is an account like alice.near that's way easier to use than implicit accounts like 641537c21dC82F97b7fC8AD778e99997beeE0d73
On NEAR, data usage is "funded" by holding a balance of tokens on the account which reserves the storage space. So, in order for the account to be created, it has to set aside some storage on the chain, which requires some amount of tokens to "pay" for those initial bytes of memory by sitting on the account.
This minimum balance depends on how much data the account uses and could start as low as < 1N for a basic account to ~40N for one with multifactor authentication and other bells and whistles added to it.
For more, see the docs at https://docs.near.org/docs/concepts/storage which describe the "state staking" approach used here.
https://github.com/square/connect-javascript-sdk/blob/master/docs/OAuthApi.md#obtainToken
How many access tokens can be generated per personal API token with Square SDK? A million at a time? Infinite? 100? It doesn't mention on the website, nor on any other Stripe documentation that I could find.
If you really mean Square, and you're solely talking about OAuthing other merchants (based on the link you provided) then our docs say:
By default, the OAuth API lets up to 500 Square accounts authorize your application.
It is possible to increase that number, but you would need to reach out to support and communicate the need with them.
https://docs.connect.squareup.com/api/oauth#navsection-oauth
I am currently in the process of planning & developing an integrated application using Stripe in addition to some other technologies (a combination of backbone & laravel). As a result I am using Stripejs in combination with the PHP stripe library.
I use stripejs to send Stripe their account info (for savings accounts I send country, routing and account numbers via stripes js lib, I then save off the created token in the response to the backend). I am attempting to transfer money to various recipients following charging accounts (so I have money in my stripe account) but I am a bit confused over exactly what approach to take.
My main questions are as follows.
If I am positive of the identities of the individual’s using the application, is verification required (5 – 10 people max will be using)?
If it is required what is the best approach to verifying the user using the current technique I am using (create a token, save off on the backend)?
From my experience with Stripe, you don't need to 'verify identities' each time you use a token, so long as a customer has been set up for recurring use. So as long as your application is properly secured so that only the 5-10 people can use it, and can only process payments for their own accounts, you are good to go. In other words, you obviously want to do your own user verification to make sure only valid people can use the application, but you don't need to do it as far as Stripe is concerned.
That said, if you are in essence transferring money between people, you might want to go the extra distance and make sure that the user has the correct card number or bank account number each time. In which case I would use something like:
Get user data using tokens stored in DB.
$cu = Stripe_Customer::retrieve("cus_4pn93XXXXXXXXXXX");
$card = $cu->cards->retrieve("card_14g7ZU4rLTyXXXXXXXXXXX");
If Stripe's returned data matches user-submitted data, you know you have the correct user. In particular, if the last 4 digits of the card and the expiry date match the last 4 returned by Stripe and the Stripe returned expiry date, you can be reasonably sure (albeit not certain) that the person actually possesses the card in question.
I'm working on my enterprise SaaS application and some of my users would like to be charged on a per-seat approach.
I was wondering how to make sure that the access will indeed be limited. I can see right now that people with the same login/password are logging from different IP addresses, different user agents at the same time, even though the company have paid only for one seat.
What would be the best way to implement the limitation from business and technical perspectives? I don't want to be too strict, at the same time I want companies to pay for the number of seats they actually need.
Don't filter by user agent, I think that would be too strict, some people may have a variety of browsers installed. Filtering by IP could also be tricky, some users may have a dynamic IP that changes at regular intervals.
One idea I have would be to force users to install a browser extension, the browser extension could generate a unique ID from something on the operating system. Maybe use a HDD volume number or Windows serial key, anything that will be unique to that computer.
Once you have this unique ID, use it in the back end tracking every time the user logs in. If the user exceeds a certain number of seats you can either block the user account or contact them first.
It would also be a good idea to allow the user a certain amount of freedom, so that if they have one seat then the back end will allow maybe 2 seats for a month (rolling period), this would be in-case the user buys a new pc or installs a new HDD.
Using IP seems a bad idea - people in a LAN will (usually) all have the same IP.
Assuming PHP has no API to access inspect sessions different than the current one - one idea is:
if you're not already doing it, for each login cookie you issue, also issue an unique id (an UUID will serve your purpose)
store those ids somewhere (in java you could store them in the application context, maybe in php you'll need a db table for that - I'm no php expert), together with two timestamps: "session start" and "last activity"
at each request, record the current timestamp in "last activity"
Then, when you get a new request, count how many other active have
last activity >= current session start
last activity >= now - session TTL (only needed if can't prune expired sessions in a timely fashion)
That should give you the number of occupied seats.
Note you will not notice a violation of the number of seats until after the surplus user has logged in and precisely until you see activity in some other session – I don't see any way around this issue since you don't know exactly when a seat becomes vacant (well, you might say it's vacant only when its session has expired, but that seems unfair).