Documents URL changed!

[rdavidsc]

Hi there!

I was using an extension to get data from the URL and do sonmething. But I found URL system changed.

I had before an URL like:
https://mydomain.manager/sales-invoice-view?fileID=XXXXXX&key=YYYYYYY

But now the URL is like:
https://mydomain.manager/sales-invoice-view?ogYJQ29uenVsdGVrqgYoL3NhbGVzLWludm9pY2

Can anyone point me in a direction to go?

Thanks!

[eko]

This is too cryptic to understand. Explain better with screenshots what used to happen and is no longer happening.

[rdavidsc]

Sorry… ok again:

Before, the URL was the domain plus some query parámeters. So I was able to get the company id and the document key:

• FileID → was the company ID
• key → was the id of the document

So the URL itself give me the data that I use later with the API.

For example the following URL:
https://domain.manager.io /sales-invoices ? FileID=TXlPamZpw2UgrGFuYW1h & key =ba89de75-cb87-4bde-b20f-314f01b31037

I used to get the data from the URL using a Javascript with an extension and then use it to GET or POST data to the API.

Now, in the URL I just get a single string without any keys. How can I get the FileID and the key?

[eko]

So why do you not use the Manager API?

[rdavidsc]

I do use the API.

In fact, I use an extension to detect when a user adds an invoice using JavaScript (because there is no WebHooks). Then I use the API to get the invoice data and make some calculations.

That’s why I would like to get the FileID and Key from the url as I used to. If not, I would have to Pool every certain moments the API waiting for a new invoice and wasting a lot of resources.

Thanks!

[eko]

I am using Manager Server v22.9.1.350 on Ubuntu 20.04 and my Sales Invoices links contain Key and FileID but in the following sequence (domain name deleted this is after the /).

/sales-invoice-view?Key=4e10434a-a9f3-44d1-91a6-c1d53ac2fb79&Position=1&MaxPosition=1&FileID=dGVzdCBsYXRlc3Q&Referrer=L3NhbGVzLWludm9pY2VzP1NraXA9MCZUYWtlPTUwJkZpbGVJRD1kR1Z6ZENCc1lYUmxjM1E

[Ealfardan]

I tried to reproduce your issue and I can report that the behavior is a bit perplexing. I tried to decode the query string and it appears to be recursing.

Take this query string for example:

https://{x}.manager.io/sales-invoice-view?ogYNMDAzX05vcnRod2luZKoGLi9zYWxlcy1pbnZvaWNlcz9vZ1lOTURBelgwNXZjblJvZDJsdVpNQU1BTWdNTWfCDBIJpCLnbDeLg0kRtvLVIDNYf47IDB7QDIMQ

The string

ogYNMDAzX05vcnRod2luZKoGLi9zYWxlcy1pbnZvaWNlcz9vZ1lOTURBelgwNXZjblJvZDJsdVpNQU1BTWdNTWfCDBIJpCLnbDeLg0kRtvLVIDNYf47IDB7QDIMQ

decodes to:

003_Northwind./sales-invoices?ogYNMDAzX05vcnRod2luZMAMAMgMMg	"l7I 3X

Which in turn decodes to:

003_Northwind�2	{#u

I’m not sure if this is by design or if it’s a bug.

[eko]

So maybe this is cloud server setting related as I can not reproduce it in Manager Server?

[Ealfardan]

I’m using Cloud Edition Version 22.9.5.365

[eko]

Cloud version v22.9.5.365 is ahead of Desktop and Server editions that are v22.9.1.350 so as suggested maybe it is an issue with Manager cloud.

[lubos]

It’s true URLs have changed yesterday. Not API though. Just everything else outside of API.

For the record, I do value clean readable URLs. But they do introduce extra layer of complexity into the program. It got to the point where it’s just easier for me to encode query parameters as binary data (which can be compressed if needed).

There are no secrets in query parameter. It’s just encoded differently.

I know this kind of creates a problem where URLs are no longer “guessable”. But the way I look at this, “guessable” URLs are still in API and always will be.

[rdavidsc]

@lubos

There are no secrets in query parameter. It’s just encoded differently.

How can I decode it using JavaScript?

@lubos

URLs are still in API and always will be

Good to know

[rdavidsc]

@lubos

I know this kind of creates a problem where URLs are no longer “guessable”.

Wouldn’t be a problem if there were WebHooks. I would change the word “guessable” by “usable”. Now is not usable.

[rdavidsc]

@lubos

There are no secrets in query parameter. It’s just encoded differently.

Can you please tell us how to get the query from this new way encoded string?

I just getting something like this afetr decoding base64:

(/sales-invoices?ogYJQ29uenVsdGVrwAwAyAwy bJHFv$|\

I haven’t figure out how to get the key of the document from here. This is the only thing I need.

[lubos]

@rdavidsc The query string is protocol buffers encoded in base64. The key itself is 128-bit label representing GUID.

So it’s not like there are any secrets in query string. But these query strings are not meant for API consumption or de-serializing at your end.

So rather than trying to de-serialize query string, what does your integration do and how API itself can be improved to achieve what you need?

[rdavidsc]

@lubos

what does your integration do and how API itself can be improved to achieve what you need?

Hi there! Thanks for you answer.

What I really need is to detect the moment when the user create a document (sales invoice and purchase invoice).

If there were WebHooks would be perfect because I could receive the data (FileID and key) so I could then make an API call and get the rest of the info and make some calculations like utility by invoice, commission, etc.

Meanwhile, as there are no WebHooks, what I was doing was using an JavaScript extension to detect when the user make a new invoice and send my own http request (emulating a Webhook). I used to take the FileID and key from the URL.

In addition to, now extensions are an obsolete feature…

All this described before, just to avoid to pool the API every second looking for a new invoice. WebHooks is a better solution because it saves a lot of CPU resources for both ends. The API call is made only when needed, not every second.
cBesides, when the API is called to get a list, there is no limit, no pagination, there is no filter… So every call will bring a lot of unnecessary data.

I hope you can consider to have WebHooks.

Cheers!

[Patch]

@lubos

what does your integration do

@rdavidsc

make some calculations like utility by invoice, commission, etc.

Is the API really the best way of doing this? Would not an external program call which is passed appropriate data be a cleaner solution? Similar calls are already required for tax authority reporting / integration elsewhere.

[rdavidsc]

@Patch

Would not an external program call which is passed appropriate data be a cleaner solution?

Hi @Patch !

How do you think a external program can get the appropriate data? I think the best way to make an integrations is using the API. What other solution do you propose?

In my case, that external call is made form another server where I have deployed my program. But this program need to be notified when a new invoice is created. And yes, other requirement I have is to pass the invoice data to the local tax authority.

[Patch]

@rdavidsc

requirement I have is to pass the invoice data to the local tax authority

• Which country is this for?

• Have you got your solution to submit data to your tax authority or just planning to in the future?

• Have you considered contributing to the localisation for your country?

[rdavidsc]

@Patch

Which country is this for?

Panama Republic.

@Patch

Have you got your solution to submit data to your tax authority or just planning to in the future?

Yes, there are some providers government approved and the only thing is to send them a JSON or a XML with the data. And I have to be doing this before the year ends.

@Patch

Have you considered contributing to the localisation for your country?

Yes, I would love to. I fact, I have made some language contributions several years before.