Adding custom SignIn and custom SignOut

[zagi25]

Hi everyone, my team is preparing to migrate our pages to MILO and we came across an issue.

Problem

We are working with user accounts and we have a need for some additional functionality regarding signIn and signOut of an user. Currently as far as I can tell MILO only supports default logic window.adobeIMS.signIn() and window.adobeIMS.signOut() and there is no way to configure this outside of MILO code. If I am not wrong the only way to set custom functionality for this actions is to replace signIn/signOut buttons with our own, but this means that we need to wait for IMS to be loaded and gnav to be rendered so we can access those elements and change them. And adding logic with bunch of setInterval() in our code doesn't look like the best way to do this.

Solution

I propose that we add additional properties to the CONFIG object (eg. customSignIn and customSignOut), value of this properties would be functions that will contain custom logic and they will be set as functions that will be called when click event is fired by clicking SignIn/SignOut buttons/links. In this commit you can see how this would look like commit (I didn't cover all the usages of window.adobeIMS.signIn()/window.adobeIMS.signOut()) . As you can see this addition will not interfere with the way code works now, and if new properties are not defined it will default to the way it worked before.

I would greatly appreciate your input regarding this issue and my proposed solution . If you like it and if you are willing to add this functionality to the MILO core, I would be more than happy to submit the PR for it and if not I am open for some other way to deal with this. Thank you.

[narcis-radu]

Hi @zagi25, thank you for bringing this up, the use-case should have support in Milo. I think your proposed solution makes sense, we just need to account for multiple implementations, such as the existing Profile Menu and the upcoming Universal Navigation with a brand new Profile Menu.
The only thing which is not clear yet is whether the custom sign in / out would need to execute the default behaviour and if so, would the custom code be blocking or not. Example:

customSignIn: async (defaultSignIn) => {
 await myCustomCode();
 defaultSignIn();
}

In this example, if myCustomCode is retrieving some data which can take let's say 3 seconds, then the user would see a big delay until the sign in is executed. If we only execute async code, there shouldn't be any problem.

Example two:

customSignIn: () => {
 myCustomCode();
 myOtherCode();
}

Another issue with this code is possible lack of consistency. Visitors might be already used to getting redirected to SUSI for login, but if the default method is not executed or if the visitor is redirected to a different page, we might see some issues. This would also affect global requirements for redirecting logged-in users to a specific page / feature.

I would like to understand how you plan to log in the user and if you have plans to execute the default method of adobeIMS.signIn or want to rely on Milo to provide that for you.

[mokimo]

I'd be very curious on some context of the specific use case you are trying to solve / a related ticket with more context, this would also help brainstorming on the best path to take!

[zagi25]

Hi @narcis-radu and @mokimo thanks for the fast replay. I am sorry for not providing the exact problem that I want to solve.

So we want to signin user using response_type=code , after signin, from SUSI user would be redirected to different page from the one where he was when he requested signin, after some operations are done on the back, user will be returned to the page where he started signin process and also we would set the custom cookie that has some information we need. And for the logout we want to delete our cookie.

My idea was to use adobeIms.signIn but with additional values, like response_type, redirect_uri etc. and base on this function definition it is possible to do so adobeIMS.signIn . After reading your comment @narcis-radu I realized that it is maybe better, and less prone to errors and unexpected behaviours, to give option to set this values for adobeIMS, instead of using other function. Example:

const config = {
  ...
  imsClientId: 'milo',
  imsScope: 'AdobeID,openid,gnav,pps.read,firefly_api',
  imsSignInParams: {
      redirectUri: 'https://adobe.com',
      responseType: 'code',
      state: '...'
      ...
  },
  imsSignOutParams: {
      redirectUri: 'https://adobe.com',
      ...
  },
  ...
};

I believe clientId is set to window.adobeid so we can set all of the available values there, and get response_type directly from CONFIG (or something along those lines) then in global-navigation.js and other places where we are dealing with sign In / out:

const signIn = () => {
  const { responseType} = getConfig();
  if (typeof window.adobeIMS?.signIn !== 'function') return;
  window.adobeIMS.signIn({}, {}, responseType);
}

To be honest I didn't tested this approach, but based on the adobeIMS.signIn definition it should work, and it will give us flexibility and there should not be any problems with consistency.

[Ben-Zahler]

@narcis-radu @mokimo I can also add some background on what we need in the partner portal.

• our users will be logging in/out using SUSI
• we need to control where the user gets sent after the login/logout
• we need to verify the user/ get info from a backend system, this will happen using a combination of EdgeWorkers and And IO Runtime
• we need to clear cookies on logout

I just had a long discussion with @zagi25

• for the signIn, I really like his idea of adding the adobeIMS.signing config to the CONFIG object, which means that we'd need no custom function
  • unfortunately, we found that adobeIMS has some limitations (bugs?) regarding the Authorization Code Grant Type Flow. For now it seems that we can get around this using the Implicit Grant, so no custom function is needed for now. I hope that does not change.
  • @narcis-radu a custom function existed in the "old" feds in fedsconfig.profile.customSignin, were there no similar concerns?
• for sign out, we need to clear all cookies and get the user redirected to a configurable page
  • for the user redirect after logout: Ratko found that it's possible to achieve this, so I suggest a property on the CONFIG object (e.g. CONFIG.redirectAfterLogout)
  • some of the cookies to be cleared are "http only" cookies, so we'll need to invoke a backend to clear the cookie
  • for us, the best solution would be to have a custom function or "logout endpoint" that milo calls before triggering the adobeIms singOut
  • if you are opposed to this: we could get it to work with the CONFIG.redirectAfterLogout property proposed above, but it would lead to chained redirects and I'm trying to avoid that as it increases the complexity.

[Ben-Zahler]

@narcis-radu @mokimo any update on this?
@zagi25 can support with the implementation in Milo if we have a solution/requirements that are work for Milo and our use case.

[Ben-Zahler]

@narcis-radu @salonijain3 @bandana147 it's more than three months since we raised this, this is starting to block our team.
If Milo does not want to support these requirements, we need to start looking into replacing the feds provided URL from our custom code. Please let us know what the plans are for this.
@zagi25 can support with the implementation in milo-core if you need engineering power.

[mokimo]

Contributions are always very welcome! This is just for the nav given in this commit?
Be aware that there's also the "universal navigation" which has it's own implementation of the profile and the milo global navigation just implements whatever they support. As far as I'm aware, the goal is that every project uses this universal navigation for consistency purposes.

The owners of the navigation & footer are @salonijain3 - so cc @sharmrj @bandana147 for awareness as well (best to reach out to them directly and figure out a plan, giving the initial discussion as context)

[mokimo]

PS: Discussions are great for the initial scoping & figuring out the how // getting consensus.
Beyond that for requests with a clear strategy, either a Jira ticket (in the name of Adobe.com master backlog or a specific team) or if there's no clarity #milo-dev on slack are the place to go.

If you are blocked//things aren't moving fast enough be a bit more noisy, this thread for example simply got forgotten in the void 😖

[bandana147]

@Ben-Zahler This commit? looks good and would work for navigation without Universal nav, as @mokimo mentioned above. If you are considering having a custom sign-in with Universal nav, you need to bring this to the Universal nav team first, and then we can add the support to integrate it from global navigation.

@salonijain3 @nishantka

[Ben-Zahler]

thanks @bandana147 & @mokimo ! we will not use unisersal navigation for now, so if you're fine with the proposed contribution, @zagi25 will prepare an official Milo PR in the next days. Thanks!