Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to make a new "route"?
#11
If you want centralized processing using the SSO server, then force a new login session with the 'normal' API key route. You can pass extra parameters to the server side of things with the $extras array with $sso_client->Login("", "Optional message here", $extras). Note that whatever you pass via $extras could be manipulated by malicious browsers, so you should digitally sign the data as it crosses server zones. In your 'header.php' file, write a FrontendHook_PreHeaderMessage() function that looks for your custom incoming $extras options and squirrels the information away for later use (e.g. add information to the global $sso_session_info array and then call SSO_SaveSessionInfo()). In your 'index_hook.php' file, use the stored information, if it exists, to handle payment processing before proceeding.

You should not modify the core product. Doing so inevitably breaks upgrade compatibility and, to date, I have not seen anyone modify the core without breaking the security of the product.

The reason you are getting the error message you listed is because you are passing a user session to the frontend. The frontend only works with temporary sessions and will establish a new user session after completing the authentication step. Separating temporary from user sessions eliminates a security vulnerability found in most login systems known as a session fixation attack. The frontend is sanely preventing you from breaking the security of the system.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#12
Thanks Thruska. Very well said indeed!

So is there any chance you would be able to write up an example of what to put in index_hook (server-side) to handle the request's "setuppayment" and "processpayment"? I would be eternally grateful if you could!

Thanks Thruska

James
Reply
#13
Those are things you will have to put together. You know what you want to accomplish while I don't.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#14
Thanks for getting back to me Thruska. All I need to achieve is the ability to redirect a user from the client to the server, display a page, then send them back. That's literally it!

So far, I keep getting the error mentioned previously. Other than that, it's all working! Is there any way I can (as securely as possible) redirect a user to the server (E.G; ?sso_action=makepayment) and once finished, send them back?
Reply
#15
One other alternative: Use a single client for server-side operations. Redirect to that application that uses the client which automatically signs the user in, they pay, you use the code sample I already provided above and then redirect them back when they are done. The SSO server is for signing users into applications. If you want a dedicated payment application, then you might as well make one.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#16
Hi Thruska

So sorry for the late reply. I've been working hard to try and get this working! I've considered your idea and unfortunately, due to what I ultimately need to accomplish, it wouldn't be viable.

I understand that the system/application was specifically made for signing users in and it does that very well. However, all I'm trying to do it expand it to meet my needs, it's an absolutely excellent system so it's the perfect candidate to use! I'm just struggling massively with getting it to do the simple task of displaying a page. I've tried the index hook but I'm hitting a brick wall.

So far, thanks to your suggestions and samples previously, I've managed to get it to check if a stripe_id exists for the user from the client side. Now all I need to do is redirect them to a ("custom") page on the server. That is literally it. Previous attempts throw up the error I mentioned before and following attempts end with absolutely nothing or at best, an error.

Is there any way you, or anyone else could help with a sample code or even a good indicator of how I would go about making this work? I'll use the index hook of course. The whole project has come to a halt whilst I try to figure this out and I've tried everything!

Thanks Thruska
James
Reply
#17
I'm struggling to come up with a good response knowing that you are working with a modified 'endpoint.php' file. Every single time I've ever seen someone modify the core, especially the endpoint, they blow holes open in the security of the system. Fortunately, the SSO server is stopping you from doing that as it should - the error messages the server frontend emits are there to protect both you and your users from unintentionally doing something very bad.

In light of my later response, I shouldn't have suggested writing something integrated with 'index_hook.php' but I was trying to accommodate your approach as best as possible. I still see my second suggestion as the best solution: Use a SSO client on the server side of things to implement a tiny application that processes credit cards against Stripe and then pushes the Stripe information into the SSO server via the client and then redirects the client back to where they came from. Basically, you redirect users from your main application to the credit card entry/processing application and then it redirects back again once all required conditions have been met. I've already provided all the integration source code you would need for this to work since it would operate from a pure SSO client perspective. No changes to the core product are required for this approach to work.

The only reason to use 'index_hook.php' would be to have all users enter valid credit card information into the system before returning to any application. In that case, that would happen long before the application sees the logged in user. The documentation has at least one complete working example of writing an 'index_hook.php' file. Again, no changes to the core product are required. Using hooks does not modify the core product but are considered advanced topics specific to each use-case. For advanced usage, I do assume the user already knows what to do - hopefully having written hooks/plugins/modules for other software products - and have a good grasp of the SSO server's methodology and communication cycles.

Part of my difficulty with helping you here is that I am missing or misunderstanding large pieces of the use-case. Mainly, I just don't understand why modifying the core product is the only option. I get the overall sense that the reason is along the lines of, "I've already written some code and it gets me halfway so I want to make it work all the way." A better solution to software development is that when something doesn't and clearly won't work down a specific path, revert back to a known good state and try a different approach. There is almost always a simpler, more elegant solution. If there are pieces of code that were written that still might be useful, put them into a temporary file somewhere. I do this all the time. I've probably reverted hundreds of thousands of lines of code over the years from hitting walls and it's second nature at this point. Other than hooks and header/footer files, you should revert the core product back to its original release code - especially 'endpoint.php' - and go with one of the two solutions above.

Modifying the core also ruins the upgrade path - what would you do if a security vulnerability is discovered? While I've done careful due diligence along all major OWASP vectors, it could still theoretically happen (after all, it's a 16,000+ LOC product), which could translate to being stuck with a vulnerable, difficult to upgrade application.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)
© CubicleSoft