I'm providing an eID page as an REST interface. Now I want to protect this page with an API key or similar. How can this be achieved in Typo3 8.7?
Actually it looks like this can only be done by logging in via frontend (FE) or backend (BE) and check the login status in the eID controller class.
For TYPO3 v8, you should check out the EXT:restler extension instead of using eID.
eID is meant for calls where you have to do basically everything on your own.
For TYPO3 v9, the PSR-15 middleware concept allows to individually build custom REST APIs and integrations with other solutions like SlimPHP: https://github.com/b13/slimphp-bridge
You can expect a given URL-paramter, maybe even as a post param.
Put your eID-page-configuration (typoscript) in a condition requesting this paramter to be set. Otherwise genate an error-page.
If you want to handle multiple keys (maybe from a database table) you could use a userfunc for conditions.
If you want to handle a login in the call you need to initialize more from the TYPO3 frontend. then identify the paramters from the login form (some are hidden) and provide them. AFAIK POST and GEt paramaters work.
Related
I worked with older TYPO3 versions (< v9)
I am not able to fetch the logged in backend user in my frontend extension.
In earlier TYPO3 versions I was able to do that.
Now when I logged in in TYPO3 backend and ask for it now it won't work anymore.
My approach is:
$context = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Context\Context::class);
$be_username = $context->getPropertyFromAspect('backend.user', 'username');
I am getting an empty string. I know that backend user might be not available for FE.
But I need to check on him.
Thank you for any suggestions.
If you want to find out if a Backend user is currently logged in, then the code is exactly right (you don't even need to check on the username).
$context = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Context\Context::class);
$isLoggedIn = $context->getPropertyFromAspect('backend.user', 'isLoggedIn');
However, if you do this in your extension in a Plugin, that is cacheable ("USER" cObject, or a "non-cacheable action" in an Extbase Plugin), this information could be cached, which can lead to serious! sideffects.
In general, you should only check for a backend user in Frontend-related events, PSR-15 middlewares or hooks from TSFE, not in plugins/cObjects etc. unless you really know what you are doing.
All the best,
Benni-
I am using version 8.7 of TYPO3 and intended to use a link that leads directly to the backend to edit a record (page). I tried anything like typo3/backend.php?edit=57 but got a error:
file not found
typo3/backend.php?edit=57 was the way to do it up until TYPO3 6.2, but the backend URL changed to typo3/index.php in TYPO3 7.6. It still works kind of, however you need a security token which is generated by the core. The URL now is typo3/index.php?route=%2Fmain&edit=57&token=.... There isn't really an easy way to generate URL with a valid token like that from outside TYPO3 though.
If you want to create a link inside a custom module to edit a record you can use \TYPO3\CMS\Backend\Utility\BackendUtility::editOnClick() or if you're using a Fluid template, the \TYPO3\CMS\Backend\ViewHelpers\Link\EditRecordViewHelper ViewHelper. More on that you can find here: https://docs.typo3.org/typo3cms/CoreApiReference/8.7/ApiOverview/Examples/EditLinks/
Using the extension pxa_siteimprove deep links are of the following form:
https://example.com/typo3/index.php?tx_siteimprove_goto=page:{page_uid}:{language_uid}
The parameter language_uid is optional. An example link to a page with uid 42 looks like this:
https://example.com/typo3/index.php?tx_siteimprove_goto=page:42
Optionally we can include a language uid (e.g. 1). Without a language uid set it defaults to 0:
https://example.com/typo3/index.php?tx_siteimprove_goto=page:42:1
If you want to create deep links for other purposes, you can look how this extension creates the deep link in Pixelant\PxaSiteimprove\Hooks\DeepLinkingHandler. In a first hook it just saves the page uid to the backend user session and in a later hook reuses this information to redirect to the desired page by setting the following global variable:
$GLOBALS['BE_USER']->uc['startModuleOnFirstLogin'] = 'web_layout->id=' . (int)$pageId . '&SET[language]=' . (int)$languageId;
I have been using Infusionsoft form embedded in html page but now I want to send data to Infusionsoft form using their API. I checked their APIs but could not figure out which one should be used to submit data to the Infusionsoft form. Can someone please help me with this?
https://developer.infusionsoft.com/docs/xml-rpc/
Thanks for looking into this.
Thank you, Naresh
Try to use REST API instead of XML RPC. Developer center already marked XML RPC to "legacy" module, and I guess they will replace "XML RPC" sooner or later.
Regarding to your question, you will need to define what data set you want to update.
For example, if your form is going to insert a new contact, you will need 2 things from your code.
First, prepare the parameters such like "email_addresses", "phone_numbers" and "given_name".
Second, POST request with parameters to this URL "https://api.infusionsoft.com/crm/rest/v1/contact?access_token=123abc" after authentication.
Ways to test:
Try REST API calls on page https://developer.infusionsoft.com/docs/rest/
Good luck.
To pull Webformvia API you will have to use following method, this will pull the HTML form:
Retrieve a Form's HTML
to submit a data to Infusionsoft via API
You will have to use Create contact and update contact API:
Create Contact
Update COntact
XML RPC is still in use but Infusionsoft suggests to use REST API methods
Create a Contact
Update a Contact
Single API call for two methods: Create or Update a Contact
I try to write a service module, that fetches userdata from a webservice. I found this tutorial, but it shows the 'old' way of building extensions. Is it possible to write a extbase-extension like this? How it should look like?
Extbase ("the new way") is about MVC, not about auth services, thus this tutorial is still valid.
Claus Due (an Extbase specialist) wrote an auth extension, maybe you want to study his code: https://github.com/NamelessCoder/google_auth
There are plenty of related posts to what I'm asking, but after some lengthy searches couldn't quite find what I was looking for, my apologies if it exists somewhere.
My goal -- ALL requests to my Zend App must go through a preDispatch plugin, then pass to a custom Auth controller that will decide whether existing auth credentials are sufficient for the requested operation. 'Sufficient' depends on the logic of the app, hence why I want to do this at the controller+model level. If they suffice, they send the original request along to the specified controller+action, if not they default to a 'get lost' action.
At present I'm using an auth custom plugin set in the preDispatch to simply check for POST'ed auth credentials (if we are logging in), then in all cases the plugin stores the original request and redirects everyone (auth'd or not) to my auth controller, a-la:
$request->setModuleName('default')
->setControllerName('auth')
->setActionName('check')
->setParam('oreq',$request->getParams());
My problem/question is that within my auth->check action, how should I perform the redirect after a decision is made? If I use:
$this->_helper->redirector($or['action'], $oreq['controller']);
then I obviously get an infinite loop as these requests pass through the preDispatch plugin again. Sure I could pass something with the redirect so that the Auth plugin ignores such requests, but this is clearly a security hole. I had thought about maybe generating and storing an md5 hash, storing it to session and passing that as an escape param, but that seems a little sketchy.
Any better ideas out there? Perhaps a redirect method that does not go through the standard predispatch routine in Zend App? Thanks in advance!
This is not how it is done usually in Zend Framework. Not all requests go to a common place and gets redirected to the original requested place authentication.
For access control, use Zend_Acl. Through that, you could easily determine whether the current user has the necessary auth to access the content, else redirect to 'get lost' action.
If you are still adamant on using your technique, use _forward method instead of redirect method.
Since _forward is an internal redirect, you could pass additional arguments and check that in preDispath to avoid a loop.
$this->_forward($action, $controller, $module, $params)