Activities of "sumeyye.kurtulus"

Thank you for sharing more details. However, I did not see anything that would cause this cyclical re-login problem in these files. That is why, I suspected whether you have implemented another guard on the home route.

We do not typically close tickets unless they are fully resolved or inactive for some time. We understand the issue you are facing and are actively working on a fix to prevent this from happening again. Thanks for your patience.

Hello, I didn’t fully understand your question. Could you share the steps to reproduce the issue?

Also, if you can include the property types you used when creating the entity and any related navigation details, it will help us find the right solution.

I understand your concern, and I appreciate your detailed observations. To clarify how proxy generation should work in a multi-microservice Angular project, let me walk you through an example setup:

1. I created a project named as MicroserviceTest

2. Then I added these services as my colleague has explained here.

3. Then I created the libraries for the angular project using the angular cli since each library acts as an independent module representing a specific microservice.

   • yarn ng generate library my-service-1
   • yarn ng generate library my-service-2

   The folder structure will look like this

4. Then you can run these commands to generate the proxies for the services you created:

   • abp generate-proxy -t ng -u <ServiceUrl> -m myservice1 --target my-service-1
   • abp generate-proxy -t ng -u <ServiceUrl> -m myservice1 --target my-service-2

Thanks for bringing up the documentation update. Even if updating such comprehensive documentation takes time, we will make sure this point is clearly explained to improve the developer experience. Let me know if you need further clarification!

Hello again, thank you for bringing this to our attention. We appreciate your detailed explanation. We are working on a fix for an upcoming release.

In the meantime, as a temporary workaround, I recommend using the following approach to overcome the problem:

import { Component, inject, OnInit } from '@angular/core';
import { DOCUMENT } from '@angular/common';

@Component({
  selector: 'app-faq-routing',
  standalone: true,
  imports: [],
  templateUrl: './faq-routing.component.html',
  styleUrl: './faq-routing.component.scss'
})
export class FaqRoutingComponent implements OnInit{

  protected readonly document = inject(DOCUMENT);

  ngOnInit(): void {
    this.forceScrollToTop();  
  }
  
  forceScrollToTop(): void { 
    const scrollableContainer = this.document.querySelector(
      '.lpx-content-container',
    ) as HTMLElement;

    if (!scrollableContainer) {
      return;
    }

    if (scrollableContainer.scrollTop === 0) {
      return;
    }

    scrollableContainer.scrollTo({
      top: 0,
      left: 0,
      behavior: 'smooth',
    });
  }
}

Let me know if you need further clarification or assistance.

Hello again, thank you for the details.However, we could not reproduce this issue on our end. By default, access token changes trigger a redirect to the home page. If you have set up a guard requiring re-login on the same page, this behavior may need customization.

If you could share more details for this part, this will help us provide a more accurate solution.

I have replicated the error on my end as well. It appears that the issue is related to separate services expecting targets to be placed correctly for the proxies to function as intended.

Based on your responses, I wasn’t sure if you had tried this approach. Could you confirm?

Hello, I understand that the problem persists when generating proxies for the second microservice.

To address this, please ensure you are passing the --target argument correctly for the specific project or library. The following command should work:

abp generate-proxy -t ng -url <apiUrl> -m <serviceName> --target <projectName>

Could you try this and let us know if the issue still occurs? If it does, please share any error messages or additional details so we can investigate further.

I see the issue you're facing. In the last step, tab-2 is not notified about the token update, which leads to the error. However, to assist you further, I would need more details on how the XSRF token is managed on the backend. Could you provide more information on that?

In fact, you just need to ensure that the refreshing page is aware that the antiforgery token has been updated before performing a location.assign('/') operation.

To handle this, you can use the ngx-cookie-service library to update the token properly. Here is a quick example of how you can implement this:

import { DOCUMENT } from '@angular/common';
import { Component, inject } from '@angular/core';
import { CookieService } from 'ngx-cookie-service';

@Component({...})
export class AppComponent {
  window = inject(DOCUMENT).defaultView;
  cookieService = inject(CookieService);
  antiforgeryToken = 'XSRF-TOKEN';

  constructor() {
    this.window.addEventListener('storage', (event) => {
      if (event.key !== 'access_token') {
        return;
      }
      const tokenRemoved = event.newValue === null;
      const tokenAdded = event.oldValue === null && event.newValue !== null;

      if (tokenRemoved || tokenAdded) {
        const token = this.cookieService.get(this.antiforgeryToken);
        //Added a set operation here
        this.cookieService.set(this.antiforgeryToken, token);
        location.assign('/');
      }
    });
  }
}