delphi 10

[rejetto]

Talking about FlashGet, it's now giving a forbidden error: "HTTP/1.1 403 Forbidden". Using your last Alpha11 or the Beta1 build doesn't changed functionality with FlashGet, when using the new URL scheme (?mode=auth&u=USERNAME&e=TIMESTAMP&s2=SIGNATURE). If I'm not mistaken, this could happen because this new URL scheme relies on JavaScript to complete the login and redirecting to the resource (correct me if I'm mistaken).

download managers (DM) can manage to download protected resources in several ways.
Let me know if my reasoning is correct.
1) the server replies 401, the DM asks you credentials, and you enter there.
This was working before but it is bad for security because credentials are clear text. I think we should not support it, at least until we have no https. That's why i'm now replying 403 instead. Actually, i should consider this https://en.wikipedia.org/wiki/Digest_access_authentication
Even if I guess many PHP based servers are not using this but sessions, so DM must be supporting sessions. Sessions are important for logout, I expect the browser to not be offering a 'logout' button otherwise.

2) the server uses cookie based sessions, and will give a reply that's good for browsers.
Some DM may use an internal browser to authenticate.
Some may capture the cookie.
Others will be not be able to work, and for these we have the "include password in pages", that puts credentials on all the links. No browser/javascript functionality is required for the DM.

I've removed that part in the example (because it's not relevant), but that doesn't mean the SID is empty (it is 'Set-Cookie: HFS_SID_=xxxxxxxxxxxx', where xxxxxxxxxxxx is the radom SID).

ok, so you are telling me you get a SID in the URL and a different one in a cookie?
It's strange because if the DM accesses the server with a SID in the URL, the server will 'create' a cookie but with the SAME id.
You sure? I expect this: the browser gets a cookie, then you pass the job to the DM which will get the cookie
1) from the browser, all working, directly
2) through the URL, the DM should have no cookie at this moment because didn't interact with the server yet, it sends a request without a cookie, the server accepts the SID in the URL.

I don't see in which case you should have 2 different SIDs.

If you want, it's better that you download FlashGet (on you XP virtual machine), and see how it works

i will wait your reply first.

I'm currently working to solve a DoS problem.

[LeoNeeson]

You sure? I expect this: the browser gets a cookie, then you pass the job to the DM which will get the cookie
1) from the browser, all working, directly
2) through the URL, the DM should have no cookie at this moment because didn't interact with the server yet, it sends a request without a cookie, the server accepts the SID in the URL.

I don't see in which case you should have 2 different SIDs.

i will wait your reply first.

Exactly! I'm getting 2 different SIDs: one in the browser (where I copy the link with SID), and another different SID is received by the DM (after the DM sends to HFS the link 'with SID in the URL').

These are all the steps on how I'm testing this (using my DM: FlashGet).

1) I open my browser and I copy the link with 'SID in the URL' (I don't use any 'browser integration with DM', but instead I manually copy and paste the link on the DM). On HFS I have enabled the option 'Include password in pages'. And before I leave the browser (Chrome), I check the SID cookie value of my browser (using chrome://settings/cookies), and it gives (in this example), the SID: PBuQoFR45UAAAICpsLLLPw (I did this to compare it with the SID I've got on FlashGet).

2) Then, I go to my DM (FlashGet) and I manually paste the link there (I'm pasting the link with 'SID in the URL'). And this is the result:

Code: [Select]

Tue May 19 15:29:48 2020 HTTP/1.1 403 Forbidden
Tue May 19 15:29:48 2020 Content-Type: text/html
Tue May 19 15:29:48 2020 Accept-Ranges: bytes
Tue May 19 15:29:48 2020 Set-Cookie: HFS_SID_=G2SSqVR45UAAAABUNrjvPw; path=/; HttpOnly
Like you said, the SID in FlashGet should have the same SID than the browser (since the FlashGet result is a response from the server), but instead, HFS is giving to FlashGet another SID (G2SSqVR45UAAAABUNrjvPw).

That's why it fails, because the DM is getting a different SID...

[rejetto]

ok Leo, i've used flashget and i've found the bug in HFS. It will work in next release.

Anyway, I said something wrong before: the URL for the file has no SID in it. The parameter S2 is a signature, not a session. The signature will work until you change the password of the user.

Did you see my email about the chrome version?

[LeoNeeson]

ok Leo, i've used flashget and i've found the bug in HFS. It will work in next release.

Good!

Leo, chill out, have some margarita, you don't need to always specify that your opinion counts so little Use the standard IMHO disclaimer.

I'll keep that in mind, thanks... (maybe I have my self-esteem low? )

Did you see my email about the chrome version?

Done! (I've replied the email). Sorry for the late reply and thanks for the heads up.

[Mars]

I am facing a problem:

despite deleting the hfs.lang file, commenting out the lines concerned in hfs.dpr except line 28 containing uFreelocalizer, I can't get rid of persistent Chinese translations once hfs is compiled

[rejetto]

mars, do you confirm that your problem is with your compilation and not with my exe?
if yes, moderate yourself  and move your question to the programmers corner

[Mars]

you can be reassured, your exe is clean 

the problem is probably localized with me because going back to beta2 it's the same

I'm trying to pinpoint where a replica of the hfs.lng would be stored to get rid of it


I found a track which would be in tools >> translation manager, there is grouped English Japanese French, German,
what I took for Chinese is perhaps Japanese
these languages are they of origin in my intallation of rio on the pc, it is very probable, it is necessary that I find to get rid of the surplus to confirm that it is indeed one of the causes which involves a partial translation