You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the SS_ENVIRONMENT_TYPE that you are on (dev, test, or live) influences which RealMe environment is connected with (mts, ite or prod, respectively).
This systems works at a glance, but makes it difficult to test against different RealMe environments from the same environment (e.g. testing against RealMe prod on the test website, in order to debug an issue with the live website's RealMe integration). Provided the certificates are in place, it should be more straightforward to change this with code.
Additionally, it would be ideal to have multiple different integrations supported by the one module. For example, enable the use of both login and assert with the same installation - at the moment the module supports only one or the other.
Finally, there are some use cases where multiple authentication sources make sense. For example, consider a website where you are invited to use the system and login via RealMe. If you are sent an invite, then you would want to pass through AllowCreate=true to RealMe, in order to tell RealMe that you allow people to create new RealMe accounts before returning the user back to the website. However, it doesn't make sense to pass AllowCreate=true when users are just logging into the website later (e.g. when they are not accepting an invite), because they won't be able to login with a fresh RealMe account unless they were following an invitation link. So when rendering the normal login form, you would use an auth_source that has AllowCreate=false, and when rendering the login form during the invite process, you use an auth_source that has AllowCreate=true set.
I see this working primarily by changing how the YML configuration is specified. Instead of specifying different values for mts, ite and prod, you would instead specify an entire auth_source block for each of mts, ite and prod. A quick mockup of this could be:
Once multiple authentication sources are required, the RealMeAuthenticator, login form etc. would all need to support some way of selecting the correct authentication source. This would then be controlled by the developer - for example simple websites might just configure it via YML, based on SS_ENVIRONMENT_TYPE like the current system does, where dev => mts, test => ite, prod => prod, but more complex flows could be built as well.
The text was updated successfully, but these errors were encountered:
Currently, the
SS_ENVIRONMENT_TYPE
that you are on (dev
,test
, orlive
) influences which RealMe environment is connected with (mts
,ite
orprod
, respectively).This systems works at a glance, but makes it difficult to test against different RealMe environments from the same environment (e.g. testing against
RealMe prod
on thetest
website, in order to debug an issue with the live website's RealMe integration). Provided the certificates are in place, it should be more straightforward to change this with code.Additionally, it would be ideal to have multiple different integrations supported by the one module. For example, enable the use of both
login
andassert
with the same installation - at the moment the module supports only one or the other.Finally, there are some use cases where multiple authentication sources make sense. For example, consider a website where you are invited to use the system and login via RealMe. If you are sent an invite, then you would want to pass through
AllowCreate=true
to RealMe, in order to tell RealMe that you allow people to create new RealMe accounts before returning the user back to the website. However, it doesn't make sense to passAllowCreate=true
when users are just logging into the website later (e.g. when they are not accepting an invite), because they won't be able to login with a fresh RealMe account unless they were following an invitation link. So when rendering the normal login form, you would use anauth_source
that hasAllowCreate=false
, and when rendering the login form during the invite process, you use anauth_source
that hasAllowCreate=true
set.I see this working primarily by changing how the YML configuration is specified. Instead of specifying different values for
mts
,ite
andprod
, you would instead specify an entireauth_source
block for each ofmts
,ite
andprod
. A quick mockup of this could be:Once multiple authentication sources are required, the
RealMeAuthenticator
, login form etc. would all need to support some way of selecting the correct authentication source. This would then be controlled by the developer - for example simple websites might just configure it via YML, based onSS_ENVIRONMENT_TYPE
like the current system does, wheredev => mts, test => ite, prod => prod
, but more complex flows could be built as well.The text was updated successfully, but these errors were encountered: