push_pin
lock
Some images can be loaded through customer.fcgi and some does not
Hi fellas, Im looking for help from you old-school onsite folks with an extremy odd issue. An onsite (belive me, we are pushing for them to migrate..) have the issue that neighter them, or their customer can see some images using customer.fcgi, but, using rms.fcgi as an logged in agent works fine. It also seems very random, in the same ticket, some images works, and some does not. For example the logo from the customer works in one message, the exact same logo doesn´t in the next. Fetching the base64 from Attachment works just fine and is the correct image, as well as renaming the file from /attachments Scenario: An external ticket, the message is external. Running: http*://XXXXXX/service/scripts/ customer.fcgi /getAttachment/2133444-c9lqX8IQjZNj7p8J0EMhq2g4xdhK8R9opUiaH7L8Sp0GMOeGTPd9njEpWyBJhiJP-0/image002.jpg returns a 401 But, running http*://XXXXXX/service/scripts/ rms.fcgi /getAttachment/2133444-c9lqX8IQjZNj7p8J0EMhq2g4xdhK8R9opUiaH7L8Sp0GMOeGTPd9njEpWyBJhiJP-0/image002.jpg works just fine. SuperOffice: 10.2.5 Pretty standard setup, SSO, Sales in the same site, no split attachments, old customer from around ~v.6.x Clues: The customer told me that they also have noticed that an image can work just fine, but, after some mails back and forth to the customer, the previous image(s) starts behaving this way. Can be reproduced in test enviroment. Database entries: Attachment_path: C:\SuperOffice\Service\attachments cgi_bin: /Service/scripts cgi_url: https://....se cgi_url_internal: https://....se Path or URL to www folder: /Service/ Big bag of swedish candy for anyone that have an idea, im loosing my mind here :) Edit: tried turning of SSO, users are promted with login, but, still customer.fcgi does throw a 401 Regards Pär Pettersson
22. okt. 2024 | 06:59 a.m.
Siste svar
If I'm not completly mistaken, at least in older releases of SO onsite, you had this admin-setting named something like "Exposed to internet" or something similar. I think i discussed this setting with Stian a long while ago, and that he mentioned that this setting also controlled if images would be embedded or linked in emails. Internal = embedded, Exposed = linked. But that may have changed and the above more seems lika a bug or something as some links works where other don't. But I quite often experience similar behaviours in Outlook, especially when it comes to images in the signature. Different clients offers and handles embedded images in different ways, and some of them block certain methods. I suppose that given a back and forth in a ticket, maybe using a combination of different mail clients, images might be disrupted over time. But spontainously, I would probably report this as a bug. Thought, cannot say for sure that it is. When it comes to Onsite-environments and later releases, especially if SSO is enabled. There is an additional impersonation configuration that you need to add to the web.config. If HTTPS and SSO is enabled, this settings is needed for the calls from NetServer to work as expected against the Service-module. As I understand it, when using certain Service-API-calls on NetServer, it will work as a API-proxy and then call the Service-module using these impersonation credentials. My best practices is also to use the same SymmetricKeys settings for all installed SO-components (NetServers, Service, etc). But I suppose that it is mainly important if the Service NetServer and Service uses the same encrypted keys. That might be things that is at least worth verifying as well. https://docs.superoffice.com/en/online/identity/single-sign-on/onsite-sso.html#superoffice-service /Marcus
12. nov. 2024 | 06:42 p.m.