I have implemented many multi site implementations in the past, so I get how to set up the environment. What I haven't done, is set up multiple websites that can share the same cart session.
So if you are on site1.com and add something to your cart or are logged on, when you go to site2.com you are logged in and have the same items in your cart.
From what I read around the forums, well there isn't much about the best way to share session. But I do know that using the configuration to enable SID on the frontend will pass the session id if you transfer between sites. I figured this is all you need to have, but I see where people are saying that only stores can share checkout sessions and that stores can have their own domain.
I am thinking the best way to do this is to setup multiple websites not one website multiple stores and then just make sure when linking to the other site, I use proper magento url methods to build out the link and it will pass over the SID and the users session will be transferred over.
Is this the preferred way to do this? Is there anything I need to know in terms of configuration? Is there any negatives doing it this? Is there a better way?,
Well if you want to have such possibility only for logged customers then i propose to you to use sales_flat_quote table which is represented by Mage::getModel('sales/quote').
With this model you can manage cart and focus only in passing customer identifier which would bring us to security subject... How would you pass customer identifier in secure way as SID isn't very secure.
Plus SEO doesn't like SID in URL from what i've heard.
Related
I am building an API where users and admins can interact with the same data, but with different needs.
A user can also have access to the admin panel, if he has the "admin" role.
Let's see for example we have a resource like Badges. A Badge is simply a reward when you achieve some actions into the app.
GET http://localhost/api/v1/badges
An authenticated user can call this endpoint and it returns the list of all badges, if they have it or not, with progress details.
GET http://localhost/api/v1/badges?user_id=2
with user_id parameter, we can see these details of another user (if he allows it).
But from the admin scope, I just need to see the list of all badges, without achievement details (CRUD operations).
So I have 2 options in mind:
Create "admin" endpoints: GET http://localhost/api/v1/admin/badges.
Adding custom header "X-App-Scope" to identify if I am in admin or user.
I don't like the second one because I think I will have so many if statements and behavior in the same endpoint, depending of the scope.
Because I have lots of use cases like this, I want to make sure my API architecture is good to handle user/admin needs.
Do you guys have any idea/example to manage stuff like this?
Thanks!
My personal preference is to separate admin API routes from user ones. i.e. having two routes
/api/v1/badges
/api/admin/v1/badges
You will have two unique documentation, one for each route, which makes it easier to maintain and understand
It will be easier to tell the difference between the user and the admin versions
There is no need extra code to check for request headers or url params.
It makes your middleware less complicated, especially if authentication and permissions are handled there.
It is more scalable for teams as there is only one kind of request and response format per API.
TL;DR: REST is designed in the expectation that you would use two different resources here.
The core problem is this: how would a general purpose component, like a browser, know that your special resource needs to have this custom header added?
In particular, consider the case where I send to you a copy of the URL for this resource, and nothing else. How are you to know to add the customer header to the request?
On the other hand, if you use different resources to share this information with each audience, everything just works.
The only way I found to stay as simple/clear as possible is to make multiple endpoints, for each use case:
GET http://localhost/api/v1/badges to get all badges in raw data
GET http://localhost/api/v1/users/badges to get all badges with user stats (progression, achievement...) in a transformed format
GET http://localhost/api/v1/users/{uuid}/badges to get all badges with user stats (progression, achievement...) in a transformed format for the specified user, if his profile is public
Now I have a lot of /users/XYZ endpoints, but my code seems easier to read & maintain, and I don't really need to see the code to guess what data will be returned, the conditions, etc...
I keep wondering how the other APIs are written when you have an admin section, because having /users everywhere isn't really "pretty", and I don't see that anywhere else.
We are trying to integrate our platform with Pipedrive. As far as we have researched, in a pipedrive account, there is one admin and he can add multiple users. And the users later can login in their respective accounts.
What we are trying to make sure is that once a Pipedrive account is integrated with our platform, the same account should not be integrated twice. So, I need a unique identifier, that lets me know whether the account has already been integrated.
My initial approach was to check the api key. But it was not successful, since every users in an account have different API Keys.
After a bit of research, I found out that there is an identifier called company_id which is common for all the users in an account. But I could not find anything regarding it in documentation. So, I am not 100% confident to go ahead and implement it in our code.
Does anyone have an idea about this?
Pipedrive support rep here.
The most sure-fire way to ensure this is to make a GET request against http://api.pipedrive.com/v1/users?api_token=your_token_here.
You are correct in assuming the company_id in the additional_data object in the response is static and won't change across any users on the account.
Note that a Pipedrive account may have more than one admin, and that non-admins (regular users) might have visibility (and editing) restrictions in place, which may cause some of your GET, PUT and DELETE requests to fail.
In case you're not doing this already, I'd thus advise filtering the data array from the abovementioned endpoint for user.is_you to equal true and check whether the is_admin property is set to 1 during "registration" to ensure the user setting up the integration is an admin.
Hope this helps!
I'm not quite sure what you're asking for. Are you looking for a unique identifier for each user?
Each user has an id, you can get all users by calling
https://api.pipedrive.com/v1/users?api_token=____
This will return a JSON Object with data on your users, including their names and associated IDs. Admins are just users with different privilege levels. All admins are users, but not all users are admins. All users are part of a company, the company is identified by the first part of the Pipedrive account url ie.
https://FooCompany.pipedrive.com
Are you trying to see if a certain company has been integrated already?
What is the recommended way to persist the state in a SharePoint 2013 application?
I need implement a Shopping Cart functionality in SP.
Also, it would be great if you can point me an open source implementation of a Shopping Cart in SP.
Thanks.
I would recommend persisting the data in a database. You will need to store some sort of identifier on the client (I used a cookie for the web order id along with a hashed & salted value of the order id). Once you have that bit figured out it is relatively straight forward to read/write back to the database to persist the order info.
Also going this route lets you follow up with the customer should they be logged in or identifiable (Think of the way Best Buy emails you if you leave something in the cart and never order it, marketing folks LOVE that).
Just some food for though, HTH!
I'm developing a multi-lingual site for a client in Joomla 2.5. I wonder if there is any way to auto assign newly registered users to a group based on the language they are on when they register.
I.e. so if I visit the Italian site and register I will automatically be put in the group "Italian".
The underlying reason I want to this is to better separate the forum sections in my Kunena forum so that, for example, Italian users only have access to the Italian forum. Is there a way to solve this in a better way?
Also, I understand that this is by no means any kind of guarantee for people sticking to their respective language's forum but it is a request from the client who wants to direct the users as much as possible.
As far as I know, the language information are stored inside a cookie, so you can't access them server-side.
You should create a user plugin: when the user register, you can try to guess the country using IP lookup, then add it to the linked user group.
I came up with an interesting way to solve the following problem and I want to know if there is a better way to achieve my objectives.
Basically, I'm creating a basic cms system users can register for their own microsite and have their own users. I'm using the asp.net membership api.
I wanted a way to isolate users of the various microsites from eachother so that a user authenticated with www.mysite.com/johns-site wouldn't also be authenticated with www.mysite.com/pauls-site.
I also wanted a way to associate a username with a microsite so that if a user is registered as bob on one site, it doesn't stop another user registering as bob for a different microsite.
To achieve this, I noticed that in the asp membership tables a user belongs to an application. Every time I receive a request, I have a method that switches the applicationName in the web.config based on the url.
This does meet my objectives in an easy way but feels a bit hacky. Is there an alternative way to switch applications for the membership provider?
It is possible to get/set the ApplicatioName property at run time however according to the below MSDN post it is not recommended as the property is not thread safe i.e. if multiple users are creating accounts for different applications at the same time it may not correctly allocate the ApplicationName per user.
Syntax:
Membership.ApplicationName = "MyAppName"
OR
Membership.ApplicationName = "MyAppName";
Further reading:
http://msdn.microsoft.com/en-us/library/system.web.security.membership.applicationname.aspx
Note:
You are updating the contents of the web.config file from the application code? If so this is most certainly "hacky". Plus editing the web.config will drop any active sessions (if your app uses session state of course).
I agree, it is a hack that will likely make you pay at some point.
The proper way to accomplish this would involve each virtual directory (or microsite as you say) each defining a <membership> element with the same connection string but different applicationName attribute.