Mark as read - Button about fb-unseen HOT 9 CLOSED

Yes, I guess that should be possible, but there is another issue: The POST request to change_read_status.php contains a bunch of data which needs to be sended, for example the id of the current user, the id of thread and some stamps. I just don't know how to get this data from within the facebook page and to figure out which id goes with which conversation to generate a "read request" myself :/

from fb-unseen.

ids[<postid?>]:true
__user:
__a:1
__req:3g
fb_dtsg:AQCRyOZn
phstamp:165816782121799011092

thats the data one has to compose, arent they?
postid and user are obvious, did you find something regarding the others? in which frequency do they change?

the simplest solution would be to log the requests facebook invokes and replay them if needed. i guess that was the issue you mentioned what is not currently possible in chrome?

from fb-unseen.

Yes, thats the needed data. ids[] is a bit strange, on some conversations, it looks like ids[id.0123456789...]: true, sometimes ids[msg.0123456789abcdef...]: true, but I'm pretty sure this ID identifies the conversation. But this id has nothing to do with the facebook profile id of your partner, so we need to find a way to know which "Mark as read" Button with what ID goes with which conversation / chat window.
__user is pretty easy, this is your personal, unique and never changing facebook id.
__a: 1 - I don't know, maybe to tell facebook that it should be marked as read or unread? On the conversation page you are able to toggle the read state, but well, let's just always send 1 and we will probably be fine.
fb_dtsg is a protection of csrf attacks as far as I can tell, it is the same within a single session.

Chrome does not allow it currently to look into POST requests, if the feature will be supported in future, we can easily get __user and fb_dtsg, maybe we can find even the fb_dtsg somewhere in the page without the feature. It seems like the phstamp is easy to calculate, a short Google search brings up quite a few sites, but I did not yet tested it. Still, even if we can monitor the requests and replay them, I have absolutely no idea how to tell apart the conversations from each other as we have only some arbitrary IDs.

from fb-unseen.

ids[]
maybe there are indeed two cases for this request, one the one hand mark a specific message as read and on the other hand mark a full conversation as read. would explain id and msg.
In our case the second would apply, wouldnt it?

__user
yeah, not the big thing.

__a: 1
you've explained it.

fb_dtsg
If its unique per session, i'm pretty sure we will find that somewhere on the fb page. Maybe we could wireshark log a little time and analyse that in view of where that occurres.

phstamp
if not looked it up, but if you say google yields some results, this shouldnt be a blocker.

to sum up:
ids[] , fb_dtsg and phstamp needs to be discovered. should be possible i think.

from fb-unseen.

I have Fixed It You Can Contact me

from fb-unseen.

The params are trivial to generate, the thing is not blocking it with automateds...

from fb-unseen.

Idea: poke the mobile version

https://m.facebook.com/messages/read/?tid=id.463342680407759&refid=12&pos=3&__m_async_page__=&__ajax__=&m_sess=&__dyn=REDACTED&__ajax__=true&__user=1610886412

from fb-unseen.

Thanks Filo, this is an awesome idea! I just discovered that mobile facebook does not even care about all the other parameters, this is enough:

https://m.facebook.com/messages/read/?tid=THREAD_ID

I’m now just trying to find those damn IDs, since every button needs to know which conversation ID it belongs to.

from fb-unseen.

Not a very beatuiful way, but it seems to work right now: @866fffb9bc297bf338310af5235bae914b28f22c

On the messages page there are a couple of „bigPipe“ objects in the page source, which are given huge json objects. In some of them there is also a threads key which contains a list of threads, and there can the thread id be found (the one which needs to be send) together with the user id (which can be extracted in every chatdialog from the See full conversation link) in the participants array. I think it should work fine except for group conversations, but the whole code is a bit “fragile”, I guess it can break very easily when facebook changes something.

from fb-unseen.