OC300 do not authorize hotspot guests
OC300 do not authorize hotspot guests
Good Morning/Afternoon/Evening
I am posting this thread after searching tirelessly on the internet for a solution without any success.
I work for a company that provides hotspot solutions and we have several hardware products that are already approved and operating perfectly, however, the Omada Controller OC300 has been a challenge that I explain.
During the requirements analysis process, I basically collect information about parameters in the controller itself to find out if it has at least the minimum requirements for the portal to operate, which are: Redirect URL, Radius and Walled Garden. Once these requirements are met, I perform authorization tests using POSTMAN to the the controller endpoint, which, in this case, is https://localhost:8043/4710a82f58377bb2afcf5d78fb70c737/api/v2/hotspot/login to get the Token and Cookie and https://localhost:8043/4710a82f58377bb2afcf5d78fb70c737/api/v2/hotspot/extPortal/auth to perform authorization, according to the manual: https://www.tp-link.com/br/support/faq/3231/
Endpoint to get the token and cookie
As you can see in the image above, the login to get token and cookie is successful.
Endpoint to authorize
However, as you can see in the image above,in the authorization process, I get the message:
{
"errorCode": -41501,
"msg": "Failed to authenticate."
}
And I can't find any material that tells me what's going on.
The controller I'm using for testing is local, and if anyone has any clues about what I can do to authorize the device in postman, I'd be very grateful.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
How do you configure the portal?What is the phenomenon on the client's end? Does it display the portal authentication page? Normally, for the portal to function properly, the connection between the clients and the controller should be fine. You should also make sure that no firewall or antivirus software is blocking the portal authentication pop-up. You can test it in different clients to see whether it exhibits the same behavior.
- Copy Link
- Report Inappropriate Content
Hello @Hank21, thank you for your reply.
Well, the portal is not active yet because we need to develop our backend, and this can only be done if we can authorize the client in the controller using postman. Therefore, firewall, antivirus and testing on other clients do not apply to this scenario since the captive portal is not active.
- Copy Link
- Report Inappropriate Content
The data here does not correspond to the template given by our instruction. It misses the site name and does not have the client IP.
- Copy Link
- Report Inappropriate Content
Good morning @Hank21 ,
Thank you for your reply...
Well, the thing is that I was in contact with Rick and Parker who are based in China and he advised me to ignore the manual that was publicly available because it contained errors and gave me the pdf attached to this message to configure. This happened in 2023 and it was working very well, but now it no longer works which raised my suspicion that it was some endpoint change.
I really just needed to confirm if the ENDPOINT is still the same, if so, I appreciate any help
Hank21 wrote
The data here does not correspond to the template given by our instruction. It misses the site name and does not have the client IP.
- Copy Link
- Report Inappropriate Content
Another curious fact is that until version 5.12 the name of the Cookie was TPEAP_SESSIONID and changed to TPOMADA_SESSIONID... after that, it stopped working. Note that in the image below, with TPEAP_SESSIONID the authorization occurred. Also note that the body had ClientIP and it worked.
- Copy Link
- Report Inappropriate Content
Please follow this manual and use the template in the article to test it. And there is a notice: For Controller v5.11 and above, the Cookie name is “TPOMADA_SESSIONID”.
API and Code Sample for External Portal Server (Omada Controller 5.0.15 or above)
- Copy Link
- Report Inappropriate Content
Thanks for your reply...
This was the manual followed and mentioned at the original post and it not working anymore.
I don't know if you saw it, but I mentioned that I was in contact with a development analyst from CHINA named Parker who sent me a new step-by-step guide in Word and that after I applied it everything worked until the end of 2023. So the 3231 manual no longer works.
And yes, I know that the Cookie is now TPOMADA_SESSIONID, but as I mentioned, until version 5.12 it was TPEAP_SESSIONID and after that change it stopped working.
I'll keep an eye out for new suggestions.
- Copy Link
- Report Inappropriate Content
But you didn't send any screenshot showing that using the template suggested by the manual has failed The template you use is not the same as the instruction.
What version of the controller is in use when it displays the TPEAP_SESSIONID cookie? Is that version V5.12? Do you have the exact version?
Do you have any related IDs? I tried to check any record that you contacted us, but didn't find anything. If you have, please provide me.
- Copy Link
- Report Inappropriate Content
Thanks for your reply...
i've already did all that, but here it its again:
Auth with EAP:
The EAP Instructions:
https://www.tp-link.com/br/support/faq/3231/
Auth With gateway:
The GATEWAY Instructions:
https://www.tp-link.com/br/support/faq/3231/
About Ticket, all contact with TPLINK was made directly trough whatsapp....My contact in China was Parker(+86 180 XXXX 9252) and Rick(+90 538 XXXX 6243) And man, I appreciate your efforts in helping me and I really appreciate it, but everything you're asking me to do, I had already done and mentioned above. Parker and I spent about 3 weeks (even in the early hours of the morning due to the 11-hour time difference) trying to understand why it wouldn't authorize and, when he finally figured it out, he sent me a new step-by-step guide that he made himself, which he made available to me in PDF format and which I attached above, everything worked perfectly at the time(2023)
As you can see above, he mentioned, the FAQ 3231 you suggested was out of date.
The only difference, as you can see in all the screenshots above, is that in version 5.12 that we used at the time, the cookie was TPEAP_SESSIONID, and today, even though I'm using the same version that I downloaded from the website, the cookie is TPOMADA_SESSIONID.
The version used at the time (2023) was 5.12.7
- Copy Link
- Report Inappropriate Content
Alex-Farias wrote
Another curious fact is that until version 5.12 the name of the Cookie was TPEAP_SESSIONID and changed to TPOMADA_SESSIONID... after that, it stopped working. Note that in the image below, with TPEAP_SESSIONID the authorization occurred. Also note that the body had ClientIP and it worked.
Here you can see the TPEAP_SESSIONID in V5.12 as well as the authorization success message.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 941
Replies: 12
Voters 0
No one has voted for it yet.