Activities of "sumeyye.kurtulus"

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('/');
      }
    });
  }
}

Thank you for testing the approach and sharing your findings. The difference in behavior likely comes from how session persistence, token storage, or middleware logic is handled in your solution.

For the AntiForgery token issue, it seems the XSRF token isn’t refreshing properly when logging in from another tab. You might try:

1. Ensuring the XSRF token is re-fetched on new login sessions.
2. Invalidating cached tokens on logout.
3. Checking if the storage event properly syncs authentication state.

export class AppComponent {
  window = inject(DOCUMENT).defaultView;

  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;

      //You can re-fetch and update the XSRF token here
			
      if (tokenRemoved || tokenAdded) {
        location.assign('/');
      }
    });
  }
}

Let me know if this helps or if you need further suggestions.

Hi again @improwise, I appreciate your follow-up.

We have run the necessary tests, and the projects generated from the current template do work as mobile apps. While we acknowledge the issue with Expo Web, we can confirm that this does not impact mobile functionality.

We will proceed with small fixes that do not disrupt the expected flow, ensuring a smooth experience. Once we have completed the necessary maintenance—including the aspects you mentioned—these updates will be included in the release notes.

Actually, the recommended fix should behave like this

Can you share the error details if you encounter something other than you mentioned at the beginning?

For the time being, we are not planning to host the fonts ourselves or switch to Google Fonts. However, as a temporary workaround, you can consider loading Inter from an alternative CDN or serving a local copy within your project to avoid issues with rsms.me. The exact fix will be published in the next patch version.

While a long-term approach should minimize dependencies on external font CDNs, for now, implementing a short-term fix like the below should help mitigate disruptions.

//app.module.ts
import { LPX_STYLE_FINAL } from '@volo/ngx-lepton-x.core';

@NgModule({
  providers: [
  ...
    {
      provide: APP_INITIALIZER,
      multi: true,
      useFactory: () => {
        const styles = inject(LPX_STYLE_FINAL);
        return () => {
          const index = styles.findIndex(f => f.bundleName === 'font-bundle');
          if (index !== -1) {
            styles.splice(index, 1);
          }
        };
      },
    },
  ],
 ...
})
export class AppModule {}

You can refer to Google fonts or add a query parameter for the inter.css in your styles.scss file.

// styles.scss
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
// @import url('https://rsms.me/inter/inter.css?v=1.0');

Another workaround can be replacing the font-bundle file in the angular.json

      "architect": {
          "options": {
            "styles": [
            ...
              {
                "input": "../angular/src/font-bundle.css",
                "inject": false,
                "bundleName": "font-bundle"
              },
            ...
            ],
          },
        },
      }

/* font-bundle.css */
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
/* @import url('https://rsms.me/inter/inter.css?v=1.0'); */