For example, if a user's Google Account were compromised, you could temporarily disable Sign In With Google for that user and prevent account recovery emails from being sent to the user's Gmail address.

After you have verified the token, check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.

If so, establish an authenticated session for the user.

Warning: Do not accept plain user IDs, such as those you can get with the GoogleUser.getId() method, on your backend server. A modified client application can send arbitrary user IDs to your server to impersonate users, so you must instead use verifiable ID tokens to securely get the user IDs of signed-in users on the server side.

If I wanted to integrate this with an existing login system, “signing out” would mean signing out of my own application (and not out of my Google account).

I sign in with my Google account everywhere I can to avoid having yet another password on another random website.

useInterval( () => { if (typeof window !== "undefined" && window.google) { setGoogle(window.google); setGoogleIsLoading(false); } }, googleIsLoading ? 100 : null );

We didn't add this initially because Google is not the only form of authentication we offer and it could get annoying for users that sign up with GitHub or username and password to see the Google popup all the time.

Sign in with Google is based on OAuth 2.0.

At a later time, when accessing data from Google is required, you call the authorization API to ask for the consent and get access tokens for data access. This separation complies with our recommended incremental authorization best practice, in which the permissions are requested in context.

OAuth 2.0 is also the industry-standard protocol for authorization. It provides for a set of endpoints with which relying parties integrate using HTTP.

relying parties

"Sign up with Google"

To mitigate this latency issue, the buttons are rendered in 2 steps, as follows:

The Sign in with Google button redirect flow always uses the POST method to submit the credential to your web server, whereas OAuth redirect normally uses the GET method.

The OAuth 2.0 specification considers HTTP redirection, but lacks guidance on rendering pop-up dialogs.

The user's Google account sign-in status and your app are independent of each other, except during the sign-in moment itself when you know that the user has successfully authenticated and is signed into their Google account. Users may remain signed in, they may sign out, or switch to a different Google account while maintaining an active, signed-in session on your website.

Automatic Sign-in can only happen with One Tap UX, not with the Sign in with Google button UX.

Due to security reasons, it's not allowed to add new Google sessions in an iframe.

are triggered only when users have signed in to Google before loading your web pages. This step is optional for the Sign in with Google button flow, since users are prompted to sign in to Google when the button is pressed.

In contrast to One Tap, the Sign in with Google button flow must be triggered by a user gesture.

A personalized button reminds end users that they have used Sign in with Google before, and thus helps to prevent unnecessary duplicate account creation on your website. This is especially helpful to end users who visit your website only occasionally. They may forget the login methods they used.

Sign in with Google for Web doesn't support silent sign in, in which case a credential is returned without any UI displayed. End users always see some UI, manual or automatic sign in, when a login credential is returned from Google to the relying party. This improves user privacy and control.

Authentication establishes who someone is, and is commonly referred to as user sign-up or sign-in. Authorization is the process of granting or rejecting access to data or resources.

The signed-in status of a Google Account, and your app's session state and signed-in status are distinct, separate concepts. User sign-in status to their Google Account and your app are independent of each other

To improve user privacy, display moment notifications are intentionally delayed a random amount of time when FedCM is enabled.

If you have any Workspace organization, and the app is only accessible to users within their own org, then we allow non-public domains for projects in "Internal" mode. See this link on how to make the project internal.

I'm going to close this thread which will no longer be monitored. In case you want to report a new issue or you can’t make project to be internal, please do not hesitate to create a new Issue Tracker thread describing your situation.

In development, I was able to reset the exponential cool down by removing the g_state cookie. One method for this might be to add a development-only "Clear Google One Tap Cookie" link that run an server-side action to remove the g_state cookie and then redirect back to the previous page.

The PSL nor its volunteers prescribe what browsers do with entries or their recognition/handling of entries, default behaviours, or other handling. Browsers do what browsers do, diversely, and the PSL is not the boss of them.

mutually-untrusting parties

In addition, owners of privately-registered domains who themselves issue subdomains to mutually-untrusting parties may wish to be added to the PRIVATE section of the list.

This handy table summarizes the differences between the various types of suffix:

It does provide an answer. The issue is that the Google form validates that the user has input a valid looking URL. So he needs to input an arbitrary, but valid URL, and then add that to /etc/hosts so his browser will resolve it to the address of his devserver. The question and answer are both fine as is and don't require any critique or clarification.

You can set "Authorized redirect URI" to local IP (like http://127.0.0.1/callback), it's working fine for me. What really agonizing is that google don't allow user to config an external IP (let's say your server IP like 99.99.99.99) as "Authorized redirect URI", google want the "Authorized redirect URI" to end with a public top-level domain (such as .com or .org).

The problem is that when I want to create OAuth client ID in google, it does not accept ".test" domain for "Authorized redirect URIs". It says: Invalid Redirect: must end with a public top-level domain (such as .com or .org). Invalid Redirect: domain must be added to the authorized domains list before submitting. While it accepts .test domain for "Authorized JavaScript origins" part! I saw most of the tutorials when using socialite and google api they set these in google console. http://localhost:8000 and http://localhost:8000/callback/google and google accepts them without problem with domain and generate the key and secret but I am not using mamp and I am going to continue with valet. I would be so thankful if you guide me about what is the alternative domain for .test which works fine in valet and also google accepts it?

AIs are not capable of citing the sources of knowledge used up to the standards of the Stack Exchange network. Even when Artificial Intelligence appears to cite sources for responses, such sources may not be relevant to the original request, or may not exist at all. For Stack Overflow, this means the answer may not honestly or fairly represent the sources of knowledge used, even if someone explicitly cites the Artificial Intelligence as an author in their answer.

It would be http://name./ as FQDN, but the variant without the . typically works in browsers, too.

users

Cloudflare Access has a generic OpenID Connect (OIDC) connector to help you integrate IdPs not already set in Access.

The diagram below walks through the social login process from start to finish.

Improved blank slate experiences: After a user signs in using a social media account, site owners have the ability to auto-suggest or auto-populate their settings with information held in their social account. This lets organizations create a first impression of convenience and encourage further use of their apps and site.

Smarter user improvements: When users sign in to an app or site using their social network, site owners can analyze data from that platform to establish user preferences. Developers can then use this insight to create customizable user experiences and build features that are in demand.

When users sign in to an app or site

What are the benefits of social login?

Password fatigue is real, and besides the inherent vulnerability of password logins, the idea of remembering yet another password puts users off registering for additional sites.

Sign-in process

Users can use multiple Identity Providers to sign in, and Okta can link all of those profiles to a single Okta user. This is called account linking. For example, a user signs in to your app using a different Identity Provider than they used for registration. Account linking can then establish that the user owns both identities. This allows the user to sign in from either account.

Identity Providers can significantly reduce sign-in and registration friction. This allows your users to easily access applications without needing to create passwords or remember usernames.

External Identity Providers

logIntoMicrosoft

loginTo

// NOTE: The element exists on the original form but is hidden and gets rerendered, which leads to intermittent detached DOM issues cy.contains('Next').click().wait(4000)

Use a single project to hold all platform instances of your app (Android, iOS, web, etc.), each with a different Client ID.

The Google Sign-In server-side flow differs from the OAuth 2.0 for Web server applications flow.

Okta supports the following enterprise and social Identity Provider types:

JSON HAL

curl -v -X POST \ -H "Accept: application/json" \ -H "Content-Type: application/json" \ -H "User-Agent: Mozilla/5.0 (${systemInformation}) ${platform} (${platformDetails}) ${extensions}" \ -H "Authorization: SSWS ${api_token}"

Indicates that the content of the element is an identifier with transient semantics and SHOULD be treated as an opaque and temporary value by the relying party.

logging in​

Logging In

set [x] up

can login

log in

Moreover, social logins are often implemented in an insecure way. Users, in this case, have to trust every application which implemented this feature to handle their identifier confidentially.

One such way that social media accounts are exploited is when users are enticed to download malicious browser extensions that request read and write permissions on all websites. These users are not aware that later on, typically a week or so after being installed, the extensions will then download some background Javascript malware from its command and control site to run on the user's browser.

When a user signs in, you can link the user’s Facebook account to an existing Okta user profile or choose to create a new user profile using Just-In-Time (JIT) provisioning.

It’s an unfortunate fact that many people use the same credentials to log into different accounts. This password practice is a big part of what enables account takeovers, as it increases the likelihood that hackers can use compromised credentials to access sensitive information across accounts.

As a prevention method, organizations should consider implementing passwordless practices like fingerprints or facial recognition, as well as modern authentication standards like WebAuthn, which remove passwords from the authentication experience. When organizations opt for these authentication methods, they help to mitigate the risk of stolen credentials, and minimize the chance of account takeovers.

For organizations where passwordless authentication is not yet possible, the next best option is to use adaptive multi-factor authentication (Adaptive MFA) as a security measure. This approach monitors the user’s login behavior on the basis of location, device, network, and more to determine which authentication methods to use. If the risk factor is high, then the user would be asked to submit an additional identifying factor such as an TOTP code or a one-time password.

In retail or e-commerce settings, this is particularly effective as hackers will often change details, including the shipping or email address, associated with the account. By reacting to that type of change and requesting an additional factor, adaptive MFA can better protect a customer’s sensitive data.

organization to user relationship

The default user profile is based on the System for Cross-domain Identity Management: Core Schema (opens new window) and has following standard properties

Singular Attributes

The args object is the only mechanism via which data may be injected into the callback, the callback is not a closure and does not retain access to the JavaScript context in which it was declared. Values passed into args must be serializable.

Turbo is a continuation of the ideas from the previous Turbolinks framework, and the heart of that past approach lives on as Turbo Drive.

It is important that these are not reloadable, because edits would not be reflected in those cached stale objects.

However, depending on your taste, that just might not feel right to you. You might prefer that app/services/users/signup.rb simply defines Services::Users::Signup.

In this example, we still want app/models/shapes/circle.rb to define Circle, not Shapes::Circle. This may be your personal preference to keep things simple, and also avoids refactors in existing code bases. The collapsing feature of Zeitwerk allows us to do that:

This is key for classes and modules that are cached in places that survive reloads, like the Rails framework itself.

Copyright (c) 2019–ω

Autoloading in Rails was based on const_missing up to Rails 5. That callback lacks fundamental information like the nesting or the resolution algorithm being used. Because of that, Rails autoloading was not able to match Ruby's semantics, and that introduced a series of issues. Zeitwerk is based on a different technique and fixed Rails autoloading starting with Rails 6.

superclass mismatches or partially-defined namespaces

may define Foo, instead of reopen it

That may be a broken window

descend

Since require has global side-effects, and there is no static way to verify that you have issued the require calls for code that your file depends on, in practice it is very easy to forget some. That introduces bugs that depend on the load order.

On reload, the namespaces are safe, won't be reloaded. The loader only reloads what it manages, which in this case is the adapter itself.

In Ruby, if you have several files called foo.rb in different directories of $LOAD_PATH and execute require "foo" the first one found gets loaded, and the rest are ignored.

The first example needs a custom inflection rule: loader.inflector.inflect("max_retries" => "MAX_RETRIES") Otherwise, Zeitwerk would expect the file to define MaxRetries.

It would have been fantastic to eschew this ridiculousness, because we all make fun of branded vulnerabilities too, but this was not the right time to make that stand.

With this coordination the race condition is gone.

This test has never failed, but it has a race condition on paper.

TruffleRuby is ahead-of-time compiled to a standalone native executable

Otherwise, M does not respond to works? (NoMethodError) because there was a context switch before the require triggered by autoload returned.

Preventing thread switching itself seems difficult on JVM, and would feel like a hack at best + potential for deadlocks.

If it passed before I would think it was just lucky timings.

I guess we should look at what CRuby does here but the autoload logic in CRuby seems particularly unreadable.

BTW to improve the reliability of that test I believe you would need a sleep (smaller, e.g. of 0.1) between the Thread.new and assert M.works?, otherwise it's likely the M.works? runs first and then the other thread will see the constant is autoloading and wait, and anyway that thread does not check what is defined on M. For the test to fail it needs to be the Thread.new running first and defining the constant but not yet the method, before the main thread keeps running and call the method.

This is a shell script that essentially does the same as the flaky test: #!/bin/sh cat <<EOS > m.rb module M sleep 0.5 def self.works? true end end EOS ruby -I. <<EOS autoload :M, "m" t = Thread.new { M } p M.works? EOS rm m.rb

If another thread encounters a constant it must autoload, this can cause a deadlock.

If this were to occur in a "child" thread, with a waiting parent inside the Executor, it would cause an unavoidable deadlock: the reload must occur before the child thread is executed, but it cannot be safely performed while the parent thread is mid-execution.

The Executor replaces these with a single more abstract interface.

Even Microsoft, a main proponent of this interface, does not conform to the definition.

Shifting the left display down below approximately 50 % of the height extension of the primary monitor (i.e. compromising the physical set-up, but still keeping the secondary display to the left of the primary display) generated a behavior correctly opening windows on the primary display.

Shipping is intended to be 'at cost'

Fog of war terrain system. With the randomised terrain set up, every game is different and forces you to make choices as you uncover your predefined play area and it encourages you to explore every inch of it.  

This is a fully tactile experience. No decks of cards to shuffle, no score tracks, no fiddly cubes, no confusing rules or nuances. Just a fluid set up, play and pack down experience with beautiful components.

In-app custom credentials templates are now supported. When a credentials file does not exist, rails credentials:edit will now try to use lib/templates/rails/credentials/credentials.yml.tt to generate the credentials file, before falling back to the default template. This allows e.g. an open-source Rails app (which would not include encrypted credentials files in its repo) to include a credentials template, so that users who install the app will get a custom pre-filled credentials file when they run rails credentials:edit.

Note that this option is ignored when rails environment is development or test.

ApplicationController.renderer.render inline: "<%= blog_url %>"

The url_for helpers now support a new option called path_params. This is very useful in situations where you only want to add a required param that is part of the route's URL but for other route not append an extraneous query param.

ActiveRecord::Base.serialize no longer uses YAML by default. YAML isn't particularly performant and can lead to security issues if not used carefully. Unfortunately there isn't really any good serializers in Ruby's stdlib to replace it. The obvious choice would be JSON, which is a fine format for this use case, however the JSON serializer in Ruby's stdlib isn't strict enough, as it fallback to casting unknown types to strings, which could lead to corrupted data. Some third party JSON libraries like Oj have a suitable strict mode.

authenticate_by addresses the vulnerability by taking the same amount of time regardless of whether a user with a matching email is found: User.authenticate_by(email: "...", password: "...")

MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON but it's faster and smaller.

The result is a toolkit so powerful that it allows a single individual to create modern applications upon which they can build a competitive business. The way it used to be.

ActiveRecord::Base.normalizes declares an attribute normalization. The normalization is applied when the attribute is assigned or updated, and the normalized value will be persisted to the database. The normalization is also applied to the corresponding keyword argument of query methods, allowing records to be queried using unnormalized values.

Moves the modules in lib/ to app/models and lib/integrations to app/integrations.

Eager-merging since this is a bug on prod. Happy to rework this solution as needed if another approach is preferable.

Some possible aims (also not exhaustive): We agree what code is a 'service' and what is not We agree on the interface we expect for our services We agree on the naming convention we use for services

Non-aims (but may happen anyway):

We decide on app/lib v. lib/ once and for all

As our app grows, an increasing amount of random code is landing in the app/services directory. I'm worried it will become impractical to improve on this, as the number of special cases will only increase. Some pain points off the top of my head (definitely not exhaustive):

when I was CTO of a company and someone joined, the first thing they had to do was to spend two weeks reading AWDwR from cover to cover. Once you know the framework, there is no magic, only defaults that act as a catalizer and let you fly.

One more example of a simple approach to this that might help a lot too is add a PORO generator. It could be incredibly basic - rails g poro MyClass yields class MyClass end But by doing that and landing the file in the app/models directory, it would make it clear that was the intended location instead of lib.

yeah - it is basically half the stuff you don't want autoloaded and half app/lib but it is not called app/lib because DHH does not want app/lib"

The subdirectories in app have a name that describes their contents, but app/lib means nothing. So, app/models and app/lib are at different level of abstraction, and that feels wrong to me.

It is also worth noting that lib/tasks typically has application-specific tasks, thus not fitting into the condition for lib. Which makes me question the criteria for lib

I think the real question then becomes: Where do Ruby classes, who I can't find a meaningful folder in app

I stand by what I said and I do not believe it is off-topic. Nevertheless, I realize it is your forum and if you want to silence and exclude people because something we say does not fit in your worldview, then I am certainly willing to accept this and remove myself from the forum. In the big picture, I will not be shut up or bullied and I think you owe me an apology as nothing I have said or done warrants your actions.

Going by the intended purpose of lib/ ("pending extraction"), I think lib/assets should remain (as those are assets pending extraction).

lib/ is intended to be for non-app specific library code that just happens to live in the app for now (usually pending extraction into open source or whatever).

And if it's app specific, for some reason, then app/models is fine. I don't think the trade-off here is worth it

Stuff like a generic PhoneNumberFormatter is exactly what lib/ is intended for.

The criteria for code in lib is what @dhh said above: non-app specific library code that just happens to live in the app for now (usually pending extraction into open source or whatever)

But I do question why lib and not something in app is the common suggestion for classes/modules who do not fall into the default set of folders (models, controllers, jobs, etc). Is it just because it's what we've been doing for so long? To me feels like we're trying to shoehorn the lib folder into further being a kitchen sink (now holding rake tasks and miscellaneous classes), rather than just saying "your Ruby classes/modules go somewhere in app because they're application code".

If application code lives in app, then doesn't that imply that things in lib (such as PhoneNumberFormatter) are not application code? I think that's one of the reasons why your recommendation of app/lib felt right to me -- my classes feel like they belong in app somewhere.

Yeah, I agree that lib (or app/lib

(BTW, the app/models directory is there to organize the model layer. The model layer is greater than the persisted models.)

So then they put it into lib only to find that they have to manually require it. Then later realize that this also means they now have to reboot their server any time they change the file (after a painfully long debugging time of "why what aren't my changes working?", because their lib folder classes are now second-class citizens). Then they go down the rabbit hole of adding lib to the autoload paths, which burns them because rake tasks then all get eager loaded in production. Then they inevitably realize anything inside app is autoloaded and make an app/lib per Xavier's advice.

The real fundamental problem is that lib is a kitchen sink

I think the symmetry of the naming between lib and app/lib will lead a fresh Rails developer to seek out the answer to “Why are there two lib directories?", and they will become illuminated. And it will prevent them from seeking the answer to “How do I autoload lib?” which will start them on a rough path that leads to me advising them to undo it.

Everything has a place so do better and find it. There is a certain belief that everything within app should be organized into functionally-named directories and any files placed in app/lib actually belongs in app/services or app/interactors or app/models or someplace if the developers just tried harder. The implication is that developers are bad developers if they don’t yet know what kind of constant they have and where its forever home should be. I reject this. Over the lifespan of an application, there will be constants that have not yet found their functional kin, if those kin ever come to exist at all; sometimes you simply need some code and a place to put it. app/lib can be the convention for where those constants can live temporarily or as long as necessary. Autoloading is really nice, let’s treat them to it.

It is confusing that app/lib is named similarly to lib . I agree, but it is not uncommon to have directories with the same name and similar function nested under different contexts. I believe developers can handle this complexity. Most similarly, Linux has lib and usr/lib . Within a new Rails app, there are many such directories that are manageable: app/assets and lib/assets (sometimes even vendor/assets too) app/javascript and vendor/javascript storage and tmp/storage config and app/assets/config app/controllers and app/javascript/controllers

Please note that you should also ignore subdirectories that are not meant to be namespaces. For example: Rails.autoloaders.main.ignore('lib/tasks', 'lib/assets') Otherwise, Zeitwerk would define a Tasks constant, but that is not your intention (and could potentially conflict with a genuine Tasks constant).

Another alternative that would feel a lot better would be app/my_app in the same way I do lib/my_app, and then app/my_app/my_file.rb would define MyApp::MyFile, like normal. That would be fine, preferable, even. But how do I tell Zeitwerk that?

I'm assuming some of the goals are to make it clear where to put new files (and to stay within current Rails conventions). We already have a few non-standard app folders in our project, such as app/services, app/queries, etc. and we put some non-ActiveRecord classes in app/models. If we are going to move files, it might make sense to first define where files should go, and then move each file to the appropriate place. This might be more of a reorganization project, than copying over a folder.

pp Rails.autoloaders.main.dirs

In API design, exceptional use cases may justify exceptional support. You design for the common case, and let the edge case be edge. In this case, I believe lib deserves ad-hoc API that allows users to do exactly that in one shot:

People want to autoload from lib, which is understandable. If we can, this use case should have first-class support from the framework.

lib is meant for things that are kind of tangential to the application core. What's in there feels better located in lib than under app, for me.

The OAuth Proxy, which intercepts all requests to the APIs and translates cookies to tokens.

Besides the security concerns related to potential XSS vulnerabilities, keeping the token in memory has a big downside regarding user experience as the token gets dropped on page reloads. The application must then obtain a new token, which may trigger a new user authentication. A secure design should take user experience into account.

@tmoschou You can find the source for Apple's pkill on opensource.apple.com/source. It's together with other utilities in the collection adv_cmds. Maybe you can spot the bug.

But rather than do all that work to identify the running pod, why not run the backup using the deployment? (That's what I've always done) kubectl exec deployments/gitlab --namespace gitlab -- gitlab-rake gitlab:backup:create

How to set up and validate locally Access content editor in wikis or in issues behind a feature flag :content_editor_on_issues. Copy some text from Google docs or any rich text document Press Cmd/Ctrl + Shift + V to paste raw text.

I think we are a victim of behavioural norms and so many of the apps that I use have this pattern. That's not to say it's the right behaviour, but it may be hard to break the pattern for users.

It was an intentional decision to make the items in the dropdown of content editor span two lines instead of one. The reason being that sometimes the text can get too long and the dropdown spans the entire width of page which isn't ideal. Also, a slimmer dropdown looks better on mobile devices.

Implement restrictive defaults (potentially allowing an explicit bypass) I understand that easy usability and rich out-of-the-box functionality is likely essential to this library's appeal to its users. Nevertheless I'd like to propose making the authorization properties ransackable_[attributes/associations/etc.] empty sets by default, forcing the developer to explicitly define whitelists for their use case. To soften the usability blow, a new ransack_unsafe(params[:q]) or ransack_explicit(params[:q], ransackable_attributes='*', ransackable_associations=(:post, :comment)) method could be introduced to offer developers a shorthand to bypass or override the whitelists for specific queries (after they've had to read a warning about why these methods can be dangerous).

The thing is I'm finding trouble to dedicate to Ransack lately, so I can't really commit to any date.

Postbox is Thunderbird for Mac.6ShareReportSavelevel 2TheRealKenJeong · 2 yr. agoThis is a good app. It started off as a reskinned Thunderbird client but has branched off somewhat. It's different enough at this point that it no longer supports plug-ins, but over t ime, it's assumed most functionality of the more popular plug-ins anyway.

Please contact Google for support on Gmail. This really isn't an action that has anything to do with your Mac. You can access all of your mail online in a web browser. What you would like to do isn't an action of the Mail app which is simply a client but would be managed by the ISP, in your case Google.