I’m calling the Magento (1.3.1.1) API http://MAGENTO/api/v2_soap?wsdl . And I’m getting Access Denied Soap exceptions when I call the Login method.
I have created a webservice user called Admin and assigned them to a role that has access to ‘ALL’.
I have another instance of Magento hosted on the same server and it works fine, and I have asked a colleague to give it a try, setting up their own user and calling the webservice and they experience the same problem.
**EDIT:**I tried starting from scratch again, reapplying my changes and testing at each stage. Iv managed to pin it down to something in the database as the error occurs again when I re-import the database. So I know its nothing to do with any code or template changes I have made. Still lost though!
Related
I need to create a service reference to the Magento 2 SOAP API in my Visual Studio project. So I've created an Integration in the Magento backend, gave it All access and activated it.
But when I try to access the WSDL for (ie. the customer API) at http://my.magento/soap/default?wsdl&services=customerCustomerRepositoryV1, I get the exception:
Consumer is not authorized to access %resources
Ok, I get it. I need my access token to access these specific 'admin' API's. Because public API's like 'quoteGuestCartRepositoryV1' do work. When I get the full API list at http://my.magento/soap/default?wsdl_list=1 it also only lists public/guest API's.
No problem so far, but when I try to add the 'customerCustomerRepositoryV1' as a service reference in Visual Studio, of course the authorized exception is thrown. But I have no way of actually adding the access token to the header there.
Is there a way to get access to all WSDL's anonymously? Magento 1.x used to allow this.
Yes, it is a Magento error. The WSDL is not available anonymous anymore since a recent Magento release. I think it's a stupid decision by the devs.
https://github.com/magento/magento2/issues/5330#issuecomment-255222166
And for the 'solution': https://community.magento.com/t5/Programming-Questions/Magento-2-C-APIs-SOAP-problem/m-p/49677#M1206
So I'm trying to integrate Google login with Parse using the "Bring your own login" system. I was able to get the basic authorization functionality to work using the code snippets at https://groups.google.com/forum/#!topic/parse-developers/UUvTreGYOrI.
Now, to do some testing, I went ahead and manually deleted the user object via the Parse dashboard. However, I am now getting the following error when trying to access go through the signup workflow:
com.parse.ParseRequest$ParseRequestException: {"code":101,"message":"object not found for get"}
I tried clearing the cache and uninstalling the app, but the issue persists. Can anyone help me how to get around this and start the registration process afresh?
On a more fundamental note, this is my first time implementing code OAuth, logins, and ACLs. As such, any resource/tutorial that can give me code examples of this integration with Parse on both the CloudCode and the client (app) side would be highly appreciated (I believe the current official Parse tutorial uses Git and only has samples of the server side CloudCode).
Nevermind - I figured it out.
I had to delete the entry in the TokenStorage class on the Parse dashboard. I guess that's storing the token that links the login with the User object.
Anyway - I'm keeping this open to see if someone can point me to a good sample code for this workflow.
I'm writing an app that's supposed to run with MVC5 and using parse as a backend.
I'm using the new Identity feature of the MVC5 to login an user. I also tried to use this solution but I couldn't make it work.
What is happening is that when I login with the user A and then login with the user B in a different session (a incognito windows or a new browser) whenever I try to insert something related with a ParseUser object using the first user that was logged in I get an exception: UserCannotBeAlteredWithoutSessionError.
I'm not sure if I'm doing the implementation in a wrong way, or if it is a limitation of the Parse (I think it was designed to run using one user per device).
If you have a workaround for this situation please help me.
There is a good answer which may help: Parse Database Authorization - Security For User Objects.
So, it's a kind of Parse SDK limitation, when you can work with only one user per device (as ParseUser is cached locally). The only workaround that I can see is to perform SignOut/Login explicitly, when you need to do something from other user's context. There is no way to have two users work simultaneously from the same device.
We are hosting a web app on Parse's Cloud Code Hosting service but I'm having a problem getting the logged in facebook user in Express code. I can see that the client side it working when I call Parse.FacebookUtils.logIn and I can get the user in main.js using request.user when the account is logged in from an iOS app, but the same doesn't work in app.js. I've tried following the cookie handling code in this guide https://parse.com/docs/js/api/symbols/parseExpressCookieSession.html but I still get undefined when I try and access it.
I'm sure I'm missing something obvious but I'm not sure where the process is failing.
This seems to be a reasonably common problem;
https://parse.com/questions/parseexpresscookiesession-cookie-session
https://www.parse.com/questions/parseusercurrent-on-express-is-undefined-when-loggin-with-facebook
Then I finally came across this;
https://github.com/ParsePlatform/parse-facebook-user-session
I have MVC application which uses Forms authentication. For some reason any session variable that I declare are not saving whenever the user is not logged in. My application needs to support both authenticated and unauthenticated users. The applications works fine when ran locally. The issue only occurs on our remote server. We're using appfabric for session state. I'm trying trouble shoot the issue but I don't know where to start. Any advice would be welcomed!
Edit-when I change the value for httpCookies domain = "future.domain.com" to httpCookies domain="" it works fine. I was told by our admins that we need this setting to not change.