I am really confused, not at this stuff but at what your saying and not reading.
I am not sure why your not reading things:
You seem to think I am disagreeing with you on some things where I am not. your glossing over the things I am saying and I think you do not realise a number of things about open platform.
In terms of SOAP TheBCMan, your actually incorrect on the authentication and just doing an app using username and password creates a big problem in the scope of an app.
In terms of email and password - This has to be a user. So what your saying in terms of an app that may be on the app store etc - Someone has to create a user access or configure the app with their details before it will work. This is only viable for a one off app and custom solution for 1 site and either requiring a user slot for an app or needing one created.
This option is not really viable if your creating a true open platform app and has those problems and overkill in terms of your code access.
"To use a site token instead of username/password, send an empty username field and the site token as the password. See example below."
This works great, and you can see it is right there in the documentation. So there is a token.
What this means for your app, and the reason this is here is that you can create an app through SOAP (and again, we got apps out there doing this! lol) and NOT require a username and password. You do not have to request it in your app, no manual setup, no need to have a user or ensure a user exists in an app, works with any user, changes to users in the admin etc.
This means that the app can be sold viable to multiple people as a proper product, its less code and no use requirements.
- Liam is confusing a REST API with the SOAP XML API.
No, I know what is REST and what is SOAP, I also have been talking BC about open platform testing it etc, and for some time. Also helped with feedback on what is more important to turn into REST. BC plan to do so as I mentioned with those conversations.
What you are not reading and understanding is what works in terms of open platform and between and app and 3rd party server data which is what I mentioned.
- Even if you needed an authentication token (which you do not) it still would be possible to use Javascript with said token.
Yep, as I mentioned, and Yes, in terms of viable apps on sale you need to use the authentication token, not username and password option - Thats a bad idea and not a viable selling app. And it is more straight forward with the authentication token, so your also over complicating things.
- YOU CAN with Javascript in a BC app (admin area) access the full SOAP XML API. NOTE: You need to put usernames and passwords in the JavaScript so there is that security consideration.
No need for username and password, and as I keep saying which your ignoring, I am 1. not talking about this in most of the bits I have said and 2. WE DO THIS, we were the first having this working in open platform (Which has been available to us through alpha as partner advisory board partners)
- YOU CAN access the API with plain old HTML and JS from the front end of the site (in this case ONLY a 3rd party middle man server needed because I would never put login credentials client side).
Of course, again Pretty offers things like email validation to more complex things, BUT to be secure this needs to be done properly with good authentication. Like any decent web application and their API access etc. Your handling personal data on BC sites in the CRM etc, not doing this properly would be lazy and stupid as I am sure you agree. But based on your comments you can give people the wrong idea about open platform and apps.
- YOU ARE / I AM NOT breaking any rules or guidelines set out by BC or adobe because you are using plain old Javascript and HTML.
Not true, I have done lots of things, and provided feedback on what I have done with BC, checked with them and been advised what is valid, what is not. When I was accessing lots of elements of the admin, as I mentioned already here along with other things.. this and other reasons were the reasons why BC introduced apps under a different domain and iframe so they could not access the parent frames dom objects etc.
Because it is HTML and javascript it is also NOT true that you do not have to follow any guidelines or rules, yes you do. From HTML apps with other platforms like windows you can use javascript and HTML but there is authentication, methods etc. BC has already introduced this, apps are already sandboxed and the security features as I have already mentioned will be increased. Also, because these are built apps, you can not just go in and rip peoples code. Unlike a web app where the source is available, while you may view an app, if BC or the BC app store file code ripped from other apps, this breaks that apps copyright and you will be liable.
It is early days for open platform but from ownership to security and data access they are very much in the scope of app and are/will and continue to be in that scope. Like I said, if your hacking Webapp API now outside of an app - BC do not want you to do it and will close the loop holes.
- Security is my number 1 focus on any project every time, I would not compromise security of any development work I did for easy of use or a cool idea. I would turn away work before compromising yours or my security on a project.
That is great to here, I do not expect or consider any different from someone with the experience you have. You should fully well understand that despite it being Javascript and HTML or because of It as well in other regards, BC are working to introduce increased security to open platform as they already have from the first iterations. I am not sure why your arguing me on this if this is how you feel?
I am still not sure what your having ago at me for.